Ok, I recognize I would be downvoted into oblivion with this question, especially given my stance around the matter, however i really should see some honest, thoughtful debate around the merits from the presently recognized enterprise application design paradigm.
I'm not believing that entity objects should exist.
By entity objects I am talking about the normal things we often build for the programs, like "Person", "Account", "Order", etc.
My current design philosophy is:
- All database access should be accomplished via saved methods.
- If you need data, call a saved procedure and iterate on the SqlDataReader or even the rows inside a DataTable
(Note: I've also built enterprise programs with J2EE, java folks please substitute the equvalent for my .Internet good examples)
I'm not anti-OO. I write plenty of classes for various reasons, simply not organizations. I'll admit that the large area of the classes I write are static assistant classes.
I'm not building toys. I am speaking about large, high volume transactional programs used across multiple machines. Web programs, home windows services, web services, business to business interaction, take your pick.
I have tried personally OR Mappers. I've written a couple of. I have tried personally the J2EE stack, CSLA, along with a couple of other counterparts. I haven't only used them but positively developed and maintained these programs in production conditions.
I have started to the fight-examined conclusion that entity objects are becoming within our way, and our way of life could be so much simpler without one.
Think about this simple example: you receive a support call in regards to a certain page inside your application that's no longer working properly, maybe among the fields isn't being endured like it ought to be. With my model, the developer designated to obtain the problem opens exactly 3 files. An ASPX, an ASPX.CS along with a SQL file using the saved procedure. The issue, which can be military services weapons parameter towards the saved procedure call, takes minutes to resolve. However with any entity model, you'll almost always turn on the debugger, start walking through code, and you'll finish track of 15-20 files open in Visual Studio. When you step lower to the foot of the stack, you didn't remember in which you began. We are able to only keep so other areas of our heads previously. Software programs are incredibly complex without adding any unnecessary layers.
Development complexity and troubleshooting are simply one for reds of my gripe.
Now let us discuss scalability.
Do designers understand that every single time they write or modify any code that interacts using the database, they have to perform a throrough research into the exact effect on the database? And not simply the expansion copy, I am talking about a mimic of production, to help you observe that the extra column at this point you require for the object just invalidated the present query plan along with a are convinced that was running in 1 second will take 2 minutes, simply because you added just one column towards the choose list? Also it works out the index at this point you should get is so large the DBA will have to change the physical layout of the files?
Should you let people get too far in the physical data store by having an abstraction, they'll create havoc by having an application that must scale.
I'm not a zealot. I'm able to be convinced should i be wrong, and perhaps I'm, since there's this type of strong push towards Linq to Sql, ADO.Internet EF, Hibernate, J2EE, etc. Please consider your reactions, should i be missing something I actually want to know what it's, and why I ought to change my thinking.
It appears such as this real question is all of a sudden active again, significantly improved we now have the brand new comment feature I've said on several solutions. Just replies, I believe this can be a healthy discussion.
I most likely must have been more obvious that i'm speaking about enterprise programs. I truly can't discuss, say, a game title that's running on someone's desktop, or perhaps a mobile application.
One factor I must set up here at the very top in reaction to many similar solutions: orthogonality and separation of concerns frequently get reported as good reasons to go entity/ORM. Saved methods, in my experience, are the most useful illustration of separation of concerns will be able to think about. Should you disallow other use of the database, apart from via saved methods, you can theoretically redesign your whole data model and never break any code, as long as you maintained the inputs and results from the saved methods. They're an ideal illustration of programming by contract (just as long as you avoid "choose *" and document the end result sets).
Request someone who's been in the market for any very long time and it has labored with lengthy-resided programs: the number of application and UI layers came and gone while a database has resided on? How hard could it be to tune and refactor a database when you will find four to five different persistence layers producing SQL to access the information? You cannot change anything! ORMs or any code that creates SQL lock your database in stone.