July 9, 2020
Hot Topics:

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

  • By Udi Dahan
  • Send Email »
  • More Articles »

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 C4ISR 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 over the country. His experience spans technologies related to Command & Control systems, Real Time applications, and high-availability Internet services.

Page 2 of 2

This article was originally published on September 2, 2005

Enterprise Development Update

Don't miss an article. Subscribe to our newsletter below.

Thanks for your registration, follow us on our social networks to keep up-to-date