Background
Building line-of-business applications is complicated. You have to keep track of shifting business requirements, aggressive deadlines, and internal politics. Once you’ve added such things as security, performance, scalability, to the list, you will be able to see why so many projects fail, and, even where they are delivered, why important items such as usability are side-stepped.
To succeed, we need to grasp anything we can find that promises an advantage. We often look hopefully to new abstractions. Moving from assembler to compiled code brought substantial gains. Object oriented languages, RAD tool and 4GLs all brought their own snakes and ladders to the game of application development.
SQL itself is a wonderful abstraction and a 4GL in its right. ORM tools, such as NHibernate, seek to build on these abstractions to simplify the work of putting together a line-of-business application.
NHibernate promises to shield us from the complexity and tedium of writing SQL statements; in much the same way that C was designed to shield us from the complexity and tedium of manipulating registers.
There are tradeoffs with any abstraction, and sometimes they leak. Sometimes the abstractions create more problems than they solve. If we stick to best practices, it will help us to avoid areas that are most prone to problems. It puts us in a better position to judge whether the use of the abstraction actually helps to deliver the application at all.
Helping to Keep Murphy at Bay
Sometimes bad things happen to even the best software, but we can take steps when using NHibernate, to prevent, or at least avoid, the worse catastrophes. We need to follow a few ‘best practices’ to help improve the odds of success. These are:
Remember that NHibernate is not a silver bullet
Do not use HQL, use ICriteria or LINQ syntax
Avoid implicit transactions
Avoid Select N+1
Periodically check the performance with a good profiler
Use Fluent Mapping
There are more no doubt additional best practices, but this makes a good place to start.
Not a Silver Bullet
NHibernate is not a silver bullet that can slaughter the bugbears that lurk in your database. It will not make fundamental problems in the database magically expire. It isn’t an alternative to refactoring the database. If anything, these problems will be exacerbated with a tool like NHibernate. If you work on solving these fundamental problems first, before using NHibernate, then you will simplify the transition to an ORM.
The following best practices hold true whether you are using an ORM or not. These are mostly database best-practices that should be followed regardless of your development environment. A tool like NHibernate does not diminish the need for these best practices.
Create Foreign Key Constraints for every Foreign Key relationship used
If you do not have foreign key constraints defined, then you must define them before attempting to implement an ORM tool. Chances are that the lack of foreign key constraints is masking underlying issues with the integrity of the data. While NHibernate will work without every foreign key being defined with a constraint, it makes your database vulnerable to integrity violations, and it slows the database down because the Query Optimizer uses this information in its task of determining the best query strategy. If your data model cannot survive the process of adding foreign keys and constraints; you have more fundamental problems that NHibernate will not help with. On the contrary, these problems will only serve to complicate the process of implementing NHibernate.
Ban Composite Keys
Read more: Simple-talk
Building line-of-business applications is complicated. You have to keep track of shifting business requirements, aggressive deadlines, and internal politics. Once you’ve added such things as security, performance, scalability, to the list, you will be able to see why so many projects fail, and, even where they are delivered, why important items such as usability are side-stepped.
To succeed, we need to grasp anything we can find that promises an advantage. We often look hopefully to new abstractions. Moving from assembler to compiled code brought substantial gains. Object oriented languages, RAD tool and 4GLs all brought their own snakes and ladders to the game of application development.
SQL itself is a wonderful abstraction and a 4GL in its right. ORM tools, such as NHibernate, seek to build on these abstractions to simplify the work of putting together a line-of-business application.
NHibernate promises to shield us from the complexity and tedium of writing SQL statements; in much the same way that C was designed to shield us from the complexity and tedium of manipulating registers.
There are tradeoffs with any abstraction, and sometimes they leak. Sometimes the abstractions create more problems than they solve. If we stick to best practices, it will help us to avoid areas that are most prone to problems. It puts us in a better position to judge whether the use of the abstraction actually helps to deliver the application at all.
Helping to Keep Murphy at Bay
Sometimes bad things happen to even the best software, but we can take steps when using NHibernate, to prevent, or at least avoid, the worse catastrophes. We need to follow a few ‘best practices’ to help improve the odds of success. These are:
Remember that NHibernate is not a silver bullet
Do not use HQL, use ICriteria or LINQ syntax
Avoid implicit transactions
Avoid Select N+1
Periodically check the performance with a good profiler
Use Fluent Mapping
There are more no doubt additional best practices, but this makes a good place to start.
Not a Silver Bullet
NHibernate is not a silver bullet that can slaughter the bugbears that lurk in your database. It will not make fundamental problems in the database magically expire. It isn’t an alternative to refactoring the database. If anything, these problems will be exacerbated with a tool like NHibernate. If you work on solving these fundamental problems first, before using NHibernate, then you will simplify the transition to an ORM.
The following best practices hold true whether you are using an ORM or not. These are mostly database best-practices that should be followed regardless of your development environment. A tool like NHibernate does not diminish the need for these best practices.
Create Foreign Key Constraints for every Foreign Key relationship used
If you do not have foreign key constraints defined, then you must define them before attempting to implement an ORM tool. Chances are that the lack of foreign key constraints is masking underlying issues with the integrity of the data. While NHibernate will work without every foreign key being defined with a constraint, it makes your database vulnerable to integrity violations, and it slows the database down because the Query Optimizer uses this information in its task of determining the best query strategy. If your data model cannot survive the process of adding foreign keys and constraints; you have more fundamental problems that NHibernate will not help with. On the contrary, these problems will only serve to complicate the process of implementing NHibernate.
Ban Composite Keys
Read more: Simple-talk