ORM: It’s time to do some real work
I am convinced that there are developers out there who see Object-Relational Mapping, otherwise known as "getting stuff from a database", as the greatest challenge mankind has ever faced. It is a bit like Synchronization: programmers dedicate their lives solving it over and over again because it’s technical enough to be fun, and lets them avoid working on real problems.
If getting stuff from a database was so hard, how did we do it in VB 6? How did we do it in .NET 1.1? Sure, the way we did it wasn’t perfect. Say all you want about the pitfalls of using ADO.NET Commands and Connection classes, but they work. We solved the problem. A little bit of manual coding involved? Heaven forbid, you big baby. Then we solved it again with the DataSet designer and the various abstractions it introduced. Then with code generators. Now again with EF and LINQ to SQL.
I don’t know about you, but getting stuff from a database is simply not a problem I have. It just doesn’t keep me awake at night.
Ted Neward described the ORM space as the Vietnam of computer science. I’d describe it more like a Formula 1 race. There’s many players involved, they pour months and months of energy into winning the race, but all they actually do is go around and around in circles without actually going anywhere.
Filed under: Uncategorized
Oh man, this really strikes a chord with me.
As I’ve said on my own blog - I feel so bad because I’m not using all the latest whiz-bang stuff like ORM technologies, but my code works, and it’s not *that* big a deal to write a few SqlCommands to populate some objects.
Still - you have no doubt invoked the ire of the ALT.NET community and will have Scott Bellware knocking down your door in no time at all!
I agree with what I think your primary point is. Some people waste too much time on implementing a fancy solution to ‘getting data from the database’ when they really just need to get the project done and focus on the important stuff that will affect the user’s experience.
However, I think there is a lot of room for advancement in ways to ‘get data from the database,’ and I’m glad there are people out there on the cutting edge trying to figure out better and better methods.
The important thing is though, they go round and round really fast !
Many (most?) developers interact with databases on a daily basis. Creating a solid foundation that is fast and reusable is extremely important. It can make or break a project. That is why ORM is so important.
In other words…I don’t agree with ya =\
Yeah, data access isn’t hard, and a lot of the features available in a ORM come under the banner of ‘YAGNI’ for most people.
One size fits all solutions are popular with people who dont want to think about what their set of requirements actually are.
I dont think @sbellware would disagree here….
Personally I think using approaches like BDD will take you down a road where you mock out DAL issues and you’ll quickly get a very clear idea about what sort of things you need your DAL to do. In which case, you’ve gotten yourself into a good position to decide whether an ORM or a ‘roll your own’ DAL is the way to go.
ORMs shouldnt be seen as some sort of data access dogma. If you genuinely need the complex features they provide, then go for it. Otherwise, YAGNI reigns supreme.
I think there are two parts to what is considered an ORM these days. There is the trivial and potentially tedious work that turns SQL query results into objects and persists objects back to SQL that can easily be done with some ADO.NET.
Then there is also the infrastructure for managing object life-times (dirtied objects, caching) and, to a point, enforcing aggregate boundaries and concurrency issues.
It is the former that you seem to discuss in your post but it is the latter that keeps _me_ awake at night.
Understand the first principles, understand how to code it yourself, but also remember that sometimes you will better serve your client by spending your time solving their business problems rather than coding something that already exists.
Of course this assumes you and your team are familiar with the chosen ORM solution and won’t be wasting time learning it or fighting it’s limitations.
Regards,
what a load of rubbish. getting stuff from the db is an interesting problem and worth investigation and being solved in a nice fashion. how crazy to claim that just because it doesn’t affect you means it isn’t a problem at all. and even more arrogant to suggest that people working in the field go around in circles? just a load of crap.
I think ORMs have merit…I’d just think of it as a free race car, why spend all that time writing code to get stuff from the db when someone else who seems to think that sort of thing is interesting has already done it, and probably better. That’s win for me.
You are an avid fan of Data binding correct?
Well I put it to you that that ORM is to the business layer tier as Data binding is to the Presentation layer. Its all about getting stuff done.
Why would you mock people for not wanting to write reams of code? Developing applications is an expensive proposition. Any tool that can make our applications cheaper and more reliable is alright by me.
Because data binding is MY race
I’m not saying we shouldn’t find better ways to solve problems. But I’m a bit tired of hearing people have discovered the Ultimate way to map to databases, and that their solution is better than every other solution, and that there’s simply no better way to do data access (until they release their next version), and then arguing with the other racers about how wrong their approach is.
And I think we’ve proven over the last 20 years that there’s no magical line of code that will solve every ORM problem. So why are we convinced we’ll find it? Do we devote this much of our time to other parts of the application? I doubt it.
The “Boo hoo, you big baby” was deliberately there to incite a response. I don’t think people are “babies” for wanting to write less, better code. I just wish we’d put as much effort into other areas of the application as we do in the ORM layer
I think this one is flamebait Paul
If you’re doing domain driven design, then limitations in your ORM are a big deal.
We’ve been working hard for decades to separate the persistence concern from business logic so that complexity can be managed and evolved over time.
Any programmer can get data into or out of the database, that’s barely an interesting problem at all. For that purpose, even ISAM did a fair job.
Writing maintainable, intent-revealing models on the other hand, is much much harder. Getting the domain model right is a challenge, and anything that introduces additional constraints, like persistence, is going to get a lot of critical attention.
Of course, this you know, since you’ve just devoted a bunch of your own time to furthering the same causes!!! (e.g. Bindable Linq)
BTW, maintained any substantial VB6 database apps lately?
Hi Nicholas,
I’m sure we can build better ORM’s, but using SqlCommand within an encapsulated class gives a “good enough” seperation. It’s not like we have never achieved decoupled designs before, it’s just that we haven’t found a solution everyone agrees on.
I’m not arguing that every ORM-related technology since ADO.NET isn’t worthwhile; just that it I think it gets a disproportionate response to the size of the problem.
Hi Paul,
I do see your point. I guess it depends on the kind of application you’re writing. Using SqlCommand encapsulated within ‘business objects’ can work initially, but as complexity builds, the strain on the database grows exponentially.
E.g. Two operations on two entities each make a database call. Add a third entity that uses the other two entities in a larger operation. If you’re lucky this won’t be in a loop. This operation now makes two database calls. Repeat. 4 calls. Repeat. 8 calls… 16 calls…
I worked on a system that had been written this way (most still are.) Some complex features resulted in literally thousands of database calls, often for the same information again and again.
This was a massive problem - one of several that to me justify the effort that has gone into creating good ORMs.
Lazy loading, caching, identity maps etc. all do their part in avoiding this and other similar issues. Makes a big difference to me, anyway.
Aside from the laziness factor, I have a database aversion that I think is well-reasoned… As a developer, it should be my job to tell the computer _what_ I want done - take this data and persist it until I ask for it again. A computer should be smart enough to know _how_. But it’s not: instead, after you’ve said “I want to store this” - you have to decide how to map it to some data store, and how far to normalize the data, what data types to use, what indexes, what other systems my use the data, whether to use natural keys or not, and so on. Once you’re good at it (ie no longer a baby =), you can make those decisions pretty quickly, but they are still “how” questions that, at least in my mind, a computer should be smart enough to handle without much help from me. In probably no other aspect of development do you have to make so many inane _how_ decisions, and to me that’s distracting from the “real” work of expressing the “what”.
Getting stuff from a database is not hard, it’s just tedious and error prone IMO. Also a well establish ORM will actually help the database design process. If for whatever reason your database schema doesn’t work with one of the major ORM chance are it’s missing one of the needed PK/FK relationship somewhere.
I like your formula 1 race analogy and it bring also bring out another important concept. Because yes they are going around in circle but that doesn’t mean they can’t improve the engine or the car. Something that we all can benefit.
I do agree proper ORM is currently missing in the industry and we’re still looking for the right solution. I confess EF (currently v1b3) is not perfect and has a lot left to do.
Me been working in projects with 60+ developers involved have touched how difficult could it be doing such basic things. as an example, in a project based on our calculations 25% of the whole budget was saved just in the sake of using the right tool for data persistency - sure for a data-centric project with normal perf requirements. not every solution suits everybody and every project!
I do respect developers who spend nights working on providing tools for the rest of us. and please don’t be judgemental when we havn’t yet got the ultimate perfect solution. you could also repeat same post for many other tools/techniques/frameworks/… just don’t tell them they’re doing “NOTHING”, not fair matey
ORMs are the biggest pile ever invented.
All the so-called tech you mention is a field full of casualties especially the latest stuff.
Tragic to see you all repeat mistakes for 20 years now.
[Quote]Aside from the laziness factor, I have a database aversion that I think is well-reasoned… As a developer, it should be my job to tell the computer _what_ I want done - take this data and persist it until I ask for it again. A computer should be smart enough to know _how_.[/Quote]
hahahahahahaha, what the hell do you this a 4GL (i.e. SQL) is.
I agree.
The solution? To scrap SQL altogether, and to invent a network aware object oriented database system.
It’s the one tech area where I consider that there is a grand slam to be made today… If you get it right, I think you can knock out all the big DB and ORM players in a matter of three to five years.
Or, that’s my belief anyway…
I don’t really agree,
because for me the problem is nearly solved. I’m already working with a very complete tool with only few disadvantages.
Maybe take a look into ECO from capableobjects.com.
Peter
This posts smells of arrogance. But it is not surprising because you work for a company which hires gurus who can spend months debating the best way to compare an empty string but hardly deliver a working solution. In the real world we deliver working business solutions and do not try to impress others with our half baked thoughts.