The question that I haven’t seen anyone address is what problem or problems ORMs are supposed to solve. The problem that ORMs are supposed to solve deal with the disconnection between application side code and the database and the amount of time developers spend with database concerns. The disconnection between the database and application code refers to having to run the application to realize that the code written referenced to an invalid column. ORMs are supposed to close this gap making for a model in which the database, application, and data move together; I compile I know code is out of sync (provided I keep my Model up-to-date).
I’ve used 3 different ORMs (EF, LINQ to SQL, and N-Hibernate), on various size projects from small to large enterprise applications. In addition I’m no stranger to going about it with ADO.NET; DataReaders and mapping to classes, DataSets and various generation tools. I have seen good and bad implementations in the 3 different ORMs and with no ORM method. The majority of problems I’ve seen go back to anti-patterns, and not understanding limitations of a particular ORM. The following article (Anti-Patterns To Avoid In N-Tier Applications) does a nice job of highlighting many of these Anti-Patterns. Even the best of software architects, developers, and just smart people have participated in their share of Anti-Patterns before they discovered a design pattern and or the value of certain design principles that solved the problem created by the Anti-Pattern.
Not knowing your tool is another issue because this is where issues with performance come in. It’s clear many are unsure of the performance differences between Dynamic SQL and stored procedures in respect to executing database logic such as CRUD operations. Well the verdict is in and Dynamic commands are proven to be just as efficient as their stored procedure counterparts. Both have advantages and disadvantages. The key is knowing what they are and selecting the appropriate choice for the situation.
