I’m not sure what tedium and bugs are being talked about.
I’ll help you find it. I just “Googled” the internet, and found this: a href="http://blogs.tedneward.com/2006/06/26/The+Vietnam+Of+Computer+Science.aspx"http://blogs.tedneward.com/2006/06/26/The+Vietnam+Of+Computer+Science.aspx/a
It’s a very detailed article about all the problems with ORMs. Quite timely to the discussion, eh?
Jeff I can’t thank you enough for this post. I have been battling it out with a few developers on our CSK forums (Commerce Starter Kit) regarding OR/M and how much I hate it. The interesting thing is that most of these guys (as you mention) like it in concept but have never actually had to support it. I have, and every time I’ve removed it (Gentle, NHib, NetTiers).
I take a hard line on this: OR/M is laziness and serves programmers, not clients. You stick thousands of lines of code between your DB and BLL and you’re going to tell me your coding for speed and scalability? Never.
Vietnam is not a bit of an insensitive analogy (lives aren’t lost using OR/M … well except for the devs who throw themselves out a window once they realize how limited they are with it).
Hmmm.
I seem to have misunderstood what the impedance mismatch actually is (or everyone else here has, but that seems unlikely).
For the record, I thought it was about working on instances versus working on sets. The mapping between columns and properties has its problems, but I don’t find it a big deal day-to-day. The harder thing to overcome is the conceptual difference between “each instance can have different behaviour” and “every instance will have the same behaviour”.
Or, to quote the sqlalchemy ORM developers:
“SQL databases behave less and less like object collections the more size and performance start to matter; object collections behave less and less like tables and rows the more abstraction starts to matter.”
Both endpoints of the continuum are relevant, and I’ve worked on each of them, and a couple of shades in-between. Different trade-offs need to be made for different requirements (that’s not news, surely?).
The whole columns-properties thing feels like a mechanical problem, not an interesting one.
Owen
“I just “Googled” the internet…”
I read, and even understood the article. However, I find it overblown because I’m one of those who have accepted a data centric universe. In a large enterprise, if you accept a data centric universe (and for interoperability, that would seem wise) then you don’t try to shoehorn objects into relations. You use objects generated by your ORM to encapsulated your relations and build your business logic objects on top of those building blocks.
I guess I’m confused by the commentary that makes this seem “unsolved”. Systems I have designed are used by tens of thousands of users every day, with high concurrency and various access patterns (reporting, transactions and multi-screen edits) and it just hasn’t become a problem. Neither web products nor desktop products have made me curse my choice of ORM tool, nor have I encountered situations where I have been unable (or even hard pressed) to create a solution. Nor do I feel like I’m writing tedious and buggy code, since the only code I write at the business layer is to handle, you know, business rules?
Sure, if you insist that serialization is the only storage model you can stomach, relational databases aren’t all that hot. However, I haven’t used serialization for years because I have to share my data with reporting tools and other apps.
Why are people suddenly finding it so difficult to get data in and out of a relational database? This is not a new concept.
I’m no master of database technologies, but it seems that the relational database is just about the most efficient way of storing data right now in terms of speed and storage.
How do you enforce cardinality and referential integrity in these new “Object” databases? Or do you even care anymore? How is data integrity kept in check?
It does seem kind of silly. People have been using “relational database” methods of storing data even before the database was enforcing referential integrity, etc. on it’s own.
They were just enforcing these rules on their own on the client/application side.
So, let’s say that in a “proper” relational database, I need to change the item number of some product. Let’s say that 500,000 people have already ordered this product and each order needs to reflect this new number.
Do you have to iterate through every order object in the database to update the item number?
I totall agree that O/R Mappers are a total waste of time. They are only needed when the structure of the object is different from the structure of the relational database, so the soltion is simple - keep the two stuctures exactly the same.
I do this by having one object per database table, and each object has coded into it the structure of the table it’s dealing with. “But”, I hear you say, “this means you have to change the object each time you change the database”. Apart from the fact that even with an ORM you would still have some code to change I have found a way to make this even easier. I maintain all database structures in a special Data Dictionary application, so if I build/change a database table all I do is import it into the dictionary, then press a button to export the table structures to my application. The Dictionary generates the code that the application needs so I don’t have to do it by hand.
Easy peasy lemon squeezy.
“I take a hard line on this: OR/M is laziness and serves programmers, not clients. You stick thousands of lines of code between your DB and BLL and you’re going to tell me your coding for speed and scalability? Never.”
Autogenerated mapping layers bring a consistent method for abstracting out relations so the business layer can work with them, nothing more, nothing less. “Thousands of lines of code” is a red herring: I assume you also have forworn all the libraries, runtimes and other conveniences and code machine code without an assembler? Every day programmers work with many layers of abstraction that makes their life easier, yes. It also allows for reliability (the lower layers are tested foundations) and yes even scalability if you build resources for caching, concurrency control and the like into your mapping layer.
It would seem that such abstractions would be the bread and butter of someone providing a “commerce starter kit”.
I love when people like shawn don’t look into a subject but do have something to say about it. They ask questions like "How do you enforce cardinality and referential integrity in these new “Object” databases? Or do you even care anymore? How is data integrity kept in check?"
How do you go about learning new things Shawn? Or do you not care anymore?
*These new (sic!) things called object databases have plenty of ways for you to define your schema. You just no longer have to do it twice.
“and yes even scalability if you build resources for caching, concurrency control and the like into your mapping layer”
So I need to come up with a mapping model, which duplicates my existing DB model, then cache it, access it at run time so it can tell me how to “SELECT * FROM [Table]”? I have to be honest - to me this is a problem that has sprung up from ASP.NET in general - the ability to do too much, too easily, too often.
I just read my daughter “The Cat in the Hat Returns”. OR/M reminds me of the Cat pulling all the little cats from inside his hat to clean the pink off of the tub/dress/shoes/floor/walls/snow. Eventually he gets to Little Cat Z who has the Voom, which is all he needed in the first place … anyway…
No, abstractions are not our bread and butter. Abstraction overload causes our users confusion and it keeps me inline. Some things deserve to be painfully obvious.
we are using Datasets in our framework with the Enterprise Library.
And it works fine!
No objects… OK DataRows, DataTables are objects, but they are simple to use and powerfull.
Merge() Sort() RowState…
Peter Gfader
One problem with object relational mapping is that you have to spend money on LSD first in order to use it without difficulty.
ORM like most computer concepts is not a finished product, but rather a step in the right direction. The glorified days of coding in binary are over, as are the days of COBOL, mainframes and punchcards. To get where we have come has been one step at a time, and ORM is another step towards realising that we don’t have to make things complicated just because it’s cool or it’s “right”.
Our company developed another ORM, Habanero, because that was what was needed for the real world, where projects have to be delivered on schedule. It made complete sense and I can barely imagine doing it the old way.
yeah i definitely agree its a step in the right direction this is obvious by the fact that VS2008 will hav DLINQ or LINQ or watever MS decides to call it 
. However the point is that ORM is the way forward as long as it continues to evolve. DLINQ is cool bt is mainly concerned with the data layer, the still the other layers and issues to worry abt and most frustrating one is generally the GUI side, something that most ORM tools out there havnt tackled yet, havnt looked at Habanero. Ive searched the net, only finding stuff abt chilli’s … link to Habanero plz?
Currently I do some research on this topic to find a new approach. Does somebody know a product or technique that uses a similar approach like http://www.signumsoft.com/objectdatabase/ where the mapping basically already happens on the database?
Basically the good name of ORM has been tarnished by terrible code generators that spit out reams of barely passable code, and “comprehensive” packages that force you to manually do every aspect of the mapping - and then spit out reams of barely passable code.
You can’t change it, you can’t maintain it, and it sucks.
NHibernate can usually make a passable object model for next to any schema. If you are starting a new application then use something following the Active Record model, its simple and it works. Its probably how you wanted to design your database anyway. Diamond Binding is far and away the leader of this category - no code generation, no manual mapping, it works out the box. Can’t speak highly enough of it, its saved our development budget tens of thousands of euros.
I think that Linq solves “The Data Retrieval Mechansim Concern” quite nicely. You actually COULD do the query he lists.
I believe it would look like this:
from p1 in Person
from p2 in Person
where p1 != p2
where p1.Spouse == null
where p2.Spouse == null
where p1.IsThisAnAcceptableSpouse(p2)
where p2.IsThisAnAcceptableSpouse(p1)
select new Couple { p1, p2 };
Most ORM tools have their place somewhere in society. We can talk purism and enterprise-level applications, but Joe Soap who’s new to IT doesn’t have the capacity for an NHibernate - it’s homepage alone will cause him to break into shivers.
For all the Nokia and Toshiba and Microsoft developers out there building pyramids, there’s also the humble citizen building an app for the local corner shop who needs something simple, quick and, dare I say it, dirty.
To use an ORM?
Or not to use an ORM in my next project?
I am totally BLANK!
I have had problems in all projects irrespective of whether I used ORM or not. But I keep on using new technologies(i.e. ORMs, frameworks) because they keep me interested and motivated to build new projects
You really must read the book “Java Persistence with Hibernate”, at least Parts 1 and 2 about object-relational mapping impedance and how many problems have been solved.
I guarantee that you would look at this issue from an entirely different viewpoint.
The Real Meaning of Object Relational Mapping
Transparently persisting data from objects to a database is the idea behind the use of Object Oriented databases and ODBMS. If an O/RM acts in this regard they should in fact call themselves an O/OM (Object-Object Mapper) because they are not really dealing with relational data. On the other hand normalised data requires an O/RM to produce its objects by sourcing its translations from different tables in a database.
The reason why the war cannot be won is because the wrong weapon is being used, an O/OM. GURA is a new breed of O/RM and fulfills all the requirements of Object Relational Mapping. Check it put at www.gura.com.au