What Exactly is the Point of O/R Mappers ?

I had a recent email exchange with someone that was observing that they still had to be at least somewhat aware of the workings of the O/R Mapper and their database design when they designed their entity classes.  “To me, this is too intrusive since I have to incorporate a lot of persistence knowledge into my design whilst I'm still designing rather than being able to play around with the design and then add on the persistence.”  This actually made me think a lot of Andrew Conrad's blog postings, as well as a lot of conversations I've had with some of my architect, developer, and DBA friends over the last couple of years.

So what exactly is the point of using an O/R Mapper if its not completely “transparent”?  For me the main point is freedom -- freedom to focus on the design and not the implementation.  The architect and developers should gain time when using an O/R Mapper, since they don't have to write and maintain all the repetitious and boring persistence code.  Yes they still have to think about persistence, but they have more time to focus on better understanding the real business needs.  Similarly for the DBA -- the point is not to get rid of the DBA -- instead the DBA should be freed to better focus on the database design instead of writing stored procs.

There are other types of benefits of O/R Mappers too -- but they are also mostly about freedom.  For instance, one of the main selling points of O/R Mappers to management is that you will be able to easily target multiple database platforms.  That sounds like vendor freedom -- you can have your product work equally well with MS SQL, Oracle, MySql, or whatever database you want -- even the lowly Access.  Another feature of O/R Mappers is greater flexibility in your search and sort functionality -- which sounds like freedom from the fixed APIs of stored procedures, without however having to write and maintain your own dynamic sql.

I think all this additional freedom is well worth it -- as long as the O/R Mapper does not itself take away too much of your freedom by forcing you into its framework any more than necessary.  Some “vendor lockin” is to be expected with any library, and O/R Mappers are certainly no different, but it should be as minimal as possible.  In other words, yes you do need to realize that you are creating entities that are going to be persisted, but you shouldn't have to worry too much about the how your particular mapper accomplishes that persistence.  Of course, I think my WilsonORMapper minimizes that lockin, while maximizing the freedom.

9 Comments

  • Paul,



    You are really not talking about O/R mapping here but about any tool that allows you to map a relational database to .NET componentes.



    I mean, DeKlarit is not an O/R mapping in the strict technical sense and it has all the same advantages you described (and it does not have any of the shortcomings that Andrew Conrad described in his post ;).

  • >That said, I do have some fears that DeKlarit

    >forces too much "lockin", although I heartily

    >recommend it in some cases. My personal

    >opinion is that DeKlarit makes a great

    >prototyping tool, but that a good O/R Mapper

    >is much easier to use, with less lockin, in

    >many cases



    We can discuss about this another time... TechEd could be a good place ;)



    Regards

  • IMO the real answer inherent in the intrusiveness of OR Mappers is that they are a kludge. They are a product of the lack of market penetration of Object DB's and the lack of standardization of Object Query Languages. If we agree that we want to program in Objects, it follows that our data should be Objects.

  • Mike: That sounds good in theory, but its not real life. Why? Developers are the only ones that want objects -- the business wants data that can be queried any way they may want -- in other words relational data.

  • My ignorance is showing here, no doubt, but what kind of data cannot be represented as objects? We decided to adopt objects and your framework because dealing with data in C# was just too painful. And now though I'm waiting for Object Spaces, I can't help but think how nice it would be to get rid of the mapping between me and the information I want to represent.

  • I wasn't trying to say there was some data that could not be represented as objects if that's what it sounded like. I meant to say that business people could care less about objects -- they want to see and query data. Putting raw objects into a "database" is great for developers, but it makes query and reporting tools next to impossible, and most businesses need to get to the data outside of your applications and its definition of objects. True, OODB have mechanisms to get around this problem, but they tend to not work very well in real life -- its just shifting the object-relational mismatch somewhere else, and to a place that is far worse far business users. There is a reason OODBs haven't been successes -- they solve developer needs while leaving business needs worse than RDMSs do.

  • Thanks for the clarification Paul.

  • Paul can you clarify what you mean by 'Another feature of O/R Mappers is greater flexibility in your search and sort functionality'? I would say that exactly the opposite is true for me. The search capabilities to retrieve focused content that may not exactly map your object schema defined (think lookups and lists with only a couple of display fields) or bring back denormalized results in RDBMS code is pretty tough to map to an OR mapper. You can do this, but at what performance and complexity penalty?

  • Well I was assuming a comparison to a stored proc based system, and in that case you can only search and sort on what has been exposed through your stored procs. So the gain in flexibility would be true for any dynamic sql based system, not just O/R mappers.

Comments have been disabled for this content.