April 12, 2011 at 12:43 am
I'm aware of at least two projects where NHibernate has been used successfully for a while now (2 years or more). Having a deep understanding of NHib internals is crucial, as we've had few problems that was caused by NHib under the cover actions (excessive number of queries, INSERT/DELETEs being triggered when not required, NVARCHAR/VARCHAR strings generating large number of query plans etc).
You get to know the tool after using it for a while, so to don't get into trouble you could try using tools such as NHibernate Profiler (http://nhprof.com/) , or just SQL Server Profiler to track what NHib is actually generating. This could be performed as part of the code review if you've got one in place.
Check Ayende site for problems you may face when working with NHibernate http://nhprof.com/Learn/Alerts.
April 12, 2011 at 8:01 am
Maksymilian Mulawa (4/12/2011)
I'm aware of at least two projects where NHibernate has been used successfully for a while now (2 years or more). Having a deep understanding of NHib internals is crucial, as we've had few problems that was caused by NHib under the cover actions (excessive number of queries, INSERT/DELETEs being triggered when not required, NVARCHAR/VARCHAR strings generating large number of query plans etc).You get to know the tool after using it for a while, so to don't get into trouble you could try using tools such as NHibernate Profiler (http://nhprof.com/) , or just SQL Server Profiler to track what NHib is actually generating. This could be performed as part of the code review if you've got one in place.
Check Ayende site for problems you may face when working with NHibernate http://nhprof.com/Learn/Alerts.
Thanks for your post - I was hoping to get a few more positive responses than what has happened, so I'm grateful for it
Wayne
Microsoft Certified Master: SQL Server 2008
Author - SQL Server T-SQL Recipes
April 12, 2011 at 11:33 am
It's all about how it's used and understood. For most of the failed ORM based projects I've seen, the idea is that you let the ORM write the SQL and that's the end of it. If your idea is to map a table to an object and be done with it, then ORM is not for you.
When it comes down to it, I think the nature of an ORM guides developers into more procedural patterns and practices, which makes application design easier. Under that nature of design, it doesn't take advantage of set based operations.
Just remember, its not called MapTablesAndViewsToObjectRelationalMapping (MTAVTORM). If I recall correctly, the early days of ORMs were meant to do the equivalent of strongly typed collections.. I could be wrong though.
Viewing 3 posts - 16 through 17 (of 17 total)
You must be logged in to reply to this topic. Login to reply