July 21, 2014
Hot Topics:
RSS RSS feed Download our iPhone app

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

  • September 2, 2005
  • By Udi Dahan
  • Send Email »
  • More Articles »

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





Page 1 of 2



Comment and Contribute

 


(Maximum characters: 1200). You have characters left.

 

 


Sitemap | Contact Us

Rocket Fuel