+972 52-548-6969
Stealing from your client
I had a (great) talk yesterday, introducing Active Record. During this talk, I reused Jeremy's statements about data access. If you write data access code, you are stealing from your client.
Frans Bouma puts it beautifully:
No customer should accept that the team hired for writing the line-of-business application has spend time on writing a report-control or for example a grid control. So why should a customer accept to pay for time spend on other plumbing code? Just because the customer doesn't know any better? If so, isn't that erm... taking advantage of the inability of the customer to judge what the 'software guys' did was correct?
The context for Frans' post was a design decision from the Entity Framework team. I read Frans' post first, and I didn't quite know how to react to it, until I saw what the proposed design is. You can read the entire EF post here, but I'll try to summarize it so you can actually understand the point without going and reading the whole thing.
The problem is supporting change tracking in disconnected scenarios. In particular, you take an object from the database and send it to the presentation layer, some time later, you get the object from the presentation layer and persist it to the database again. There is a whole host of bad practices and really bad design decisions that are implicit in the problem statement, but we will leave that alone for now.
This is still a pretty common scenario, and it is more than reasonable that you would want your data access approach to support this.
Here is how you do this using NHibernate:
session.Merge( entityFromPresentationLayer );
Frans' LLBLGen support a very similar feature. In other words, it is the business of the data access framework to do this, none of the developer's business to do any such thing.
The current proposed EF design problem can be summarized in a single line.
context.ChangeRelationship(
customer1,
order1,
c=>c.Orders,
EntityState.Added);
This is code that you as the user of EF, is supposed to write.
If you write this type of code, you are stealing from your client.
This design violates the Infrastructure Responsibility Principle: Developers doesn't write infrastructure code for supported scenarios.
In other words, it is okay not to support a feature, but it is not okay to say that this is how you are supporting a feature.
This Is Broken, By Design
Comments
That negates the whole point of an ORM layer
Would it not be easier to say:
recreating the wheel is stealing from your client
:P, I think its a little sensational, I think this is just general 'ignorance' costs time.. time = money .. girls = evil? etc
The same is equally true for refactorbation etc, which is really like recreating the wheel you already made.
(where refactorbation = excessive refactoring)
I guess the key take away is that, if you really enjoy development work, you need to ensure that you can establish a professional 'divide'.. recreating the wheel and so on can be great learning experiences that teach you..but you should do this in -your- time.
I don't think we can talk about any theft here - just some developers have greater knowledge allowing them to do things more quickly using proper tools (and they often charge more), others don't know so much and have to code more or learn during development - but they usually will charge less. You usually agree to some sum of money (or a hourly rate) before the project starts, so if you deliver on time and in budget, is there any moral problem in that? You're not expected to retury part of your pay if you finish before the deadline, are you?
While I agree that the cost of this sort of infrastructure code shouldn't be passed on to the customer, I don't think that comparing EF with higher level ORMs is fair. It seems EF is attempting to act as a lower level encapsulation layer which is to be wrapped by a custom DAL.
I personally prefer lower-level control for performance-critical applications than dealing with the design decisions of an ORM developer.
I've spent countless hours debugging issues with various ORMs that tried to protect me from the details of the data model. This cost was indirectly passed to the client as, say, higher license fees (in product development).
@Stephen, thanks for introducing refactorbation into my lexicon :)
Hahahahaha......!! :P
Very controversial, very true, and while you're at it - make sure you've locked your door ;)
I started talking loudly about how MSFT was using ASP.NET AJAX as the "launching campaign" for Silverlight more than 1 year ago. Nobody believed me back then - and kept on saying; "It's Microsoft, they can support this and create beautiful code, blah, blah, blah"...
Today this is like "common knowledge".
I guess MSFT doesn't have incentives in getting people to easily switch DB neither - which a good O/RM tool would let you do...
But I am soon hitting that sweet spot of "being too good to be ignored", so I guess things will change when it comes to Ajax in ASP.NET... ;)
But Castle just lost their leader and big "Uhuru Guru" (to MSFT), I wonder if they ever will reach that sweet spot... :(
Someone should fork it..!!
Someone great, like you, maybe add up Tobin Harris on the team and try to get funding for it somehow...
Then use Rodriogo's Boo, start with some O/RM macros, kick ass, run in circles around EF. Then move on to creating some DSL for O/RM bindings...
Then the only thing left is for someone to create a beautiful GC in Mono and we're at "Compaq 2.0" (hint; Compaq was the first mainstream x86 clone which effectively conceptually drove IBM almost to bankruptcy...)
Then again I might be wrong, maybe Castle are still making beautiful code, pushing the limits and moving forward as never before...
I have been trying EF and had this very same problem.
So, how does nhibernate do it? Does it manage concurrency?
alberto,
session.Merge
To Thomas - you probably have noticed how much Microsoft lags behind the rest of the world in the developer tools area? MVC for web apps was known and used 8 years ago. OR-mappers - the same 8 years or even more. So how can you expect they will come out with something better than current state of the art? I think it will take them at least 3-4 years to have a decent ORM or web application framework - but then, the world will have moved to something better.
And yes, I couldn't agree more when you say that some smart guys hanging around here could put together a great application framework based on Boo
Besides the extra time / costs developing your own wheels costs, why would you want to do that anyway, usually what the existing wheels (frameworks) are for is tedious repetitive code, not that interesting.
Unless you set out to create your own wheels because you can do it better or what ever, then it is Ok, but then creating the wheel is you objective not using it.
Sorry for sticking with the wheel analogy.
-Mark
Well, yeah, I already read that in you post, I was asking for a bit more info/some app example. :D
Anyway, I have already found some info in the docs, thanks.
"There is a whole host of bad practices and really bad design decisions that are implicit in the problem statement, but we will leave that alone for now."
Oren, are you going to elaborate on that in a future post?
session.Merge
Does session query for the changes or are the changes stored as payload on the data from the other tier?
I disagree; completely. Simply that another has implemented some "plumbing code" is insufficient to declare that if I; as the developer, do not use it, it is theft.
Should I assume that; just because it is an entity framework from Microsoft or one of the other self-proclaimed "great" frameworks, the code is the ultimate answer which liberates all developers from... developing, writing code?
If I believe I can implement a better solution over Microsoft; or a better control than some vendor, I will. This is progression; this is innovation. This is the method by which all products and services continually improve; by someone who believes he can do a better job.
Condemning as "theft" is not well-thought logic.
Comment preview