How to Select an Object-Relational Mapping Tool for .NET

The single, most important trap to watch out for when choosing an object-relational mapping tool is this: “architecture by product.”

Architecture by product is a term I use to describe a set of symptoms that I’ve seen in projects over the years. In these projects, entire teams would spend months agonizing over product comparison tables, debating the importance and rankings of various features, all without a coherent architecture. Once the product was chosen, the decision was set in stone, and the architecture (when there was one) bent itself around the product. Needless to say, these projects became “never-ending successes.”

When choosing an object-relational mapping tool, you need to understand why you need object-relational mapping and where it will fit into your architecture.

These days, you see three common architecture types in information systems:

1. Client-Server
2. Web Application
3. Smart Client (aka N-Tier)

I’m using these terms somewhat loosely, so I’ll define what I mean by them as well as how object-relational mapping can be used in each of them.

The Client-Server architecture type, also known as Rich Client, involves software running on client machines communicating with a database server. This description does not preclude stored procedures in the database; in fact, at the time of Client-Server popularity, much guidance pointed in exactly that direction. Object-relational mapping fits right in to the architecture type, especially for well-developed domain models. It can save you quite a bit of SQL coding at the very least, and enable elegant handling of complex concurrency behaviors when fully utilized.

Click here for a larger image.

Figure 1

Figure 1 illustrates the most basic use of object-relational mapping in this architecture type. User interface elements such as controls and forms make use of business objects that represent the domain model for writing logic while employing objects in the o-r mapping library to persist changes to the database.

A best practice that has come out of this architecture type is to create an intermediary between the UI and the object-relational mapping library. In Domain-Driven-Design lingo, this intermediary is known as a Repository, but its purpose is quite simple: to encapsulate all object-relational mapping code and keep the user interface independent of it. Figure 2 illustrates these new relationships.

Click here for a larger image.

Figure 2

The suggested approach of using stored procedures in Client-Server applications can affect your choice of object-relational mapping tool. If you want to employ stored procedures in your database, be aware that many tools do not support mapping against them.

Web applications arose as an alternative to the heavy deployment footprint of Client-Server applications. The interesting point to note is that the server on which Web applications were deployed was a different kind of server than its predecessor. Interestingly, this architecture type holds much in common with Client-Server departing only in where the user interface is shown at runtime, as shown in Figure 3. The HTML shown on the client tier is not architecturally important.

Click here for a larger image.

Figure 3

What we have done in this architectural type is to physically replace all the running instances on the various client machines with a single instance on a server machine. If we had developed our repositories and business objects as “stateless”—retrieving all state from the database when needed—they could be easily ported back and forth between Client-Server and Web.

Smart clients are the latest craze in application development, rivaled only by SOA in hype. The thing that separates true N-Tier development (like smart clients) from the previous architectural types is that code that used to run on a single machine must now run, in separate pieces, on different machines. At its most basic level, smart clients entail taking user interface elements and some business logic and running them on a client machine. What isn’t clear, even at this level, is what is left to run on the server. Figure 4 shows the result of taking the previous paradigm and naively applying it under new constraints.

Click here for a larger image.

Figure 4

In what way is this architecture lacking? Well, it does not take into account issues of distribution. The interface between repositories and the object-relational mapping library, as well as the business objects was originally designed for in-process communication—a “chatty”interface. The result of exposing such an interface between machines is a drastic drop in performance. It is this kind of architecture that leads to a feature like “Support for remoted data access layer scenarios” in product comparison charts. Figure 5 shows an architecture designed for N-Tier distributed deployment.

Click here for a larger image.

Figure 5

To maintain a rich, high-performing UI experience, both repositories and business objects need to be available locally. It is a common misconception that the business objects on the client and those on the server are identical. Each serves different purposes. Business objects developed for the client exist to support UI functionality. This includes providing high quality data-binding capabilities as well as rich validation. Business objects developed for the server exist to encapsulate business rules and cooperate in transactions—transactions managed at the service layer.

There is one topic that has not yet been discussed and is the Achilles heel of object-relational mapping—reporting.

I have yet to see a single application where some kind of reporting was not required. Reporting does not necessarily beginning and ending with reports printed in either Word or PDF format. The basis of reporting is joining data of differing kinds into a single view—this view being primarily read-only. For some reason, once a developer begins using an object-relational mapping tool, all of a sudden he wants to use it for everything—reporting included.

The data used in reporting has no connection whatsoever to objects. First of all, it’s just data—not a single bit of behavior in sight. Secondly, you don’t need all of the data of all entities involved—just a bit of data from each of them. The datatable in .NET suits these needs just fine. So, even though many object-relational mapping tools may enable you to perform complex queries and get back objects, in the case of reporting you just don’t need it. That’s definitely one feature to take off of your product comparison table.

I hope that this discussion has shed some light on the place of object-relational mapping in the bigger scheme of things as well as what capabilities should be developed without it. If you have any comments or questions, please feel free to contact me at Udi@UdiDahan.com.

About the Author

Udi Dahan is a Microsoft Architect MVP, a recognized .NET expert, and manager of the C⁴ISR Systems Development Group at KorenTec. Udi is known as a primary authority on Service Oriented Architecture in Israel and consults on the architecture and design of large-scale, mission-critical systems developed all

http://www.developer.com/design/article.php/10925_3531871_1