I don't think I have ever put a technical book on Pre-Order before, but I did just that this morning for LINQ Object Relational Mapping
I can honestly say that I spend hours every working day thinking about ORM. In fact, a large percentage of my time over the past 4 years has been trying to map database tables to usable objects and to try to find a good architecture for applications that really works in the real world.
I have really high hopes for this book, and deep fears as well. I'm hoping I read it and think "I can just tweak a little bit of my design here and there and I'll be right on track."
I'm fearing that I'll read it and either a) not know what the hell they are talking about and realize I am still in way over my head, it's time to start flipping burgers, b) OMFG, this is better than what I have by a huge factor. I have to rebuild everything, or c) WTF, do none of these guys who write these books ever spend time in the real world? With most books, it's a little of all of these at one point or another.
I guess I'll just have to wait and see. The book is scheduled to be released April 28, 2008.
Subscribe to:
Post Comments (Atom)
Posts
3 comments:
Just an opinion, on ORMs in general:
ORMs are great for small utilities and websites, but for medium and large scale commercial applications, I think there's a fatal flaw in the concept.
ORMs force developers to think of their data in terms of objects. This doesn't scale well. In high-volume systems, pulling down the data from SQL to a middle-tier, modifying the data in some way, and storing it back on the database would be a disaster. Think about how many network hops, how many database calls, how many wasted CPU cycles are involved in one object manipulation. Now scale that to the order of thousands. Ten-thousands... ten millions. RDBMS's have spent years being tuned for exactly this scenario, and you have just thrown all that out the window.
ORMs also lead the developer to a whole set of other problems.
ORMs lead to a dupliation of effort. In any non-trivial SQL schema, there are relationships that are defined and enforced on the database -- those relationships need to be modeled (again) in some way in the object model. This generally is the place where the object model becomes so big as to become unweildy, and is wher the ORM concept breaks down -- all the development complexity still exists, it's just been moved from tables to objects.
Besides, it is often helpful to the developer themselves to think of data to be simply data; It doesn't matter if it can be considered to be a bunch of foos or a bunch of bars, because it's neither: it's simply "stuff". Depending on the perspective at the time of manipulation it can be considered to be a foo, or a bar, or something else entirely, but that's what the responsibility of the middle tier is.
There's a term for the problem: Object-Relational impedence mismatch.
Lots of big companies have put their considerable resources behind ORMs, and have generally met fastastically disasterous results -- Enterprise Java Beans anyone?
The alternative? Very simple: become very good at writing SQL code and implement a basic Data-Access-Layer model. Done right, there is remarkably little code that actually needs to be written.
All good points Matt. Right now, I'm focused on the LINQ world, and the damn stuff seems so easy that it would be a shame to clutter it up with a bunch of other layers.
Yet there always seems to be something lurking out there that drives people to feel the need to build these object models, whether it be a poorly designed database schema (not that we've ever worked with one of those), interchanging large clusters of data between systems, or mashing data from disparate systems into one cohesive response.
I took the step yesterday of stopping new development on a project I was working on, walking myself through the solution, and all the code, and doing a premptive cleanup of the code to make it easier to work on. I'm early in the project yet, so the complexities of the algorithms have yet to really be revealed, but beyond building a data access class that manages all my LINQ queries and my data context, I built very few other classes that weren't helper classes. Mainly configuration classes and classes to break apart logically grouped sections of code.
In this app, I don't see the need for ORM beyond LINQ. But I do want to keep up to speed with what is going on out there. Especially down the street from you. I keep hearing about this SubSonic thing, and I may need to figure that one out soon.
Luckily, that's what my job is now. Figuring out what works, and what doesn't.
BTW, this book has yet to be published. I've cancelled my order until I hear ti actually makes it to the shelves
Post a Comment