Performance when using Object Relational Mapping
Sorry, object relational mapping has been discussed in detail over various message boards, architecture groups, newsgroups and whatnot. Every now and then real-life projects are still struggling.
Most of today’s applications are developed with rich object-oriented business/domain models techniques while still using a relational database underneath. The are a lot of tools that bridge the mismatch between these two worlds. The mapping layer between your object model and relational model often called persistency layer often leads to unacceptable slow systems. The high level of abstraction is mainly the reason for certain performance problems. Most of these tools implement the Query Object Pattern. A Query Object is geared to form queries of various kinds and to turn those objects into the appropriate SQL query. The Query Object uses metadata abstracted from the relational schema and metadata (or reflection) which describes the mappings between the relational schema and object-model schema. The output produced by a Query Object is often referred to as a Dynamic Query. Since most Query Object implementations in today’s tools don’t offer the possibility to consume non-functional requirements or have self-learning capabilities, the actual SQL queries aren’t always optimal. The high level of transparency promotes the developer to stop caring about access and navigations paths into the relational database. The result, code that won’t reach the required performance, despite an otherwise good architecture. What makes it even worse are the developers or program manager accusing the object relational mapping tool for delivering poor results. Partly not true! One of the biggest mistakes you can make in this case is to ditch the object relational mapping tool and to take the “write one ourselves” approach. There’s a high probability that you’ll drown in the details of creating such a tool/framework and eventually end up making the same mistakes, or end up with a less flexible and more traditional data access layer.
Sounds familiar? Perhaps you need a tool/framework supporting the DataMapper Pattern to write mappings by hand and to save you from writing tedious code. The only (open-source, stable) .NET tool/framework I know supporting these requirements is iBATIS.