Stephen Forte’s Impedance Mismatch Post Elicits Responses from Domain-Driven Designers
The “Stephen Forte Embraces the Impedance Mismatch” topic of my LINQ and Entity Framework Posts for 7/14/2008+ post quotes Steve’s Impedance Mismatch post of June 27, 2008, following the “ADO.NET Framework Vote of No Confidence” ruckus:
What I am saying (and have been saying for a long time) is that we should accept, no, embrace the impedance mismatch! While others are saying we should eradicate it, I say embrace it.
ORM tools should evolve to get closer to the database, not further away.
His post stated earlier:
My first problem with ORMs in general is that they force you into a "objects first" box. Design your application and then click a button and magically all the data modeling and data access code will work itself out.
I concluded: Steve’s dismissal of O/RM tools in general and adoption of a data-first stance in particular makes me wonder why he’s on the Data Programmability Group’s Advisory Council whose other members predominately advocate domain-driven design.
Updated 7/28/2008: See link to Justin Etheredge’s viewpoint at end of post. Also, see comments by Frans Bouma and Jeremy D. Miller.
Responses from the NHibernate Mafia
I was surprised by the lack of uproar about Steve’s controversial data-first doctrine until I read Sam Gentile’s He Couldn't Have Said it Better post of July 26, 2008, which quotes from Ayende Rahien’s Impedance Mismatch and System Evolution post of July 25, 2008:
Let me start by saying that I absolutely reject this statement:
[The] database model is going to support far more than your application
The database model is private to the application, and is never shared with the outside world. If you need to access to my data, here is the service URL, have fun reading from it.
Ayende also points to Greg Young’s detailed Impedance Mismatch Reframing post of July 24, 2008, which refutes most of Steve’s O/RM contentions. Greg says that “this debate has become quite heated through the community,” but I didn’t see much evidence of a controversy.
I missed Jeremy D. Miller’s Ward Bell & I talk over the EF Vote of No Confidence Document post of July 22, 2008. (Ward Bell is VP of product management at IdeaBlade. I quoted Ward on EF v1 topics in my “Data Dilemma” Cover Story for Redmond Developer News’ July 15 Issue post.) Jeremy refers to Steve as a “database weenie” and makes this final point about EF in his post:
ALT.NET gets a rap for bad behavior, but in the wake of the VoNC document, I thought the traditionalists (the TechEd/INETA/Regional Director types) behaved poorly as well. The kicker for me was Stephen Forte's crack that developers want ORM's because they're too stupid and lazy to learn set-based algebra, then says that he hopes "cooler heads" will prevail later in the exact same post. Um, rank hypocrisy anyone?
Jeremy has some faith in the forthcoming EF v2 but says, “it'll be easier to start with NHibernate now and migrate to EF v2 later than it would be to start with EF v1.” If ease is the criteria, I’d say his recommendation only applies to small projects implemented by current NHibernate experts.
Update 7/28/2008: Justin Etheredge’s The Data Disconnect post of July 27, 2008 suggests a data-centric approach with service-oriented architecture (SOA) when many applications share the same data. In this case, Justin concludes:
If you are looking at a database as the center of the application, with multiple applications hitting the same database, then an ORM solution would probably look less realistic for you. ORMs biggest advantages come into play when they are generating their own SQL (so as to avoid having to maintain separate stored procs) and when you let the database schema stay relatively simple and have the translation layer massage the data into the exact format you need. These goals can often conflict with the database-centric view of an application, which likes to keep more of this control inside the database.
Atom 1.0 site feed
3 comments:
I don't agree with the oppinions voiced by Stephen Forte. Why is he on the Data Programmability Group’s Advisory Council?
This guy spent most of his precious stage time at the previous Tech-ED sessions (in Barcelona) to talk about private ventures.
When confronted numerous times about his oppinions in relation to OR/M tools (and performance related to architectures built with OR/M) it became evident that real experience was missing to back his oppinions.
It seems like a step in the wrong direction.
"I concluded: Steve’s dismissal of O/RM tools in general and adoption of a data-first stance in particular makes me wonder why he’s on the Data Programmability Group’s Advisory Council whose other members predominately advocate domain-driven design. "
It's the attitude and way of thinking of Forte that he is on that advisory board. :)
If an organisation has a problem, and can't decide what to do about it, i.e. which option(s) to pick and why, what will you do? Hire a group of people who all think the same? No, you hire a group of people who have very distinct opinions. After all: you don't need a group of people who simply follow you whatever you say, you need people who can give you DIFFERENT insights on the matter, insights which aren't available inside the organisation as the group there tends to grow its own line of thinking (as people who disagree usually leave these groups)
Reading Steve's post again, I had a good laugh. He brings up so many silly arguments that I really don't see the point replying to the guy.
However, make no mistake: his line of thinking is the one of many many potential users of the EF out there: teams with a lot of stored procs in the DB, and a corporate policy which dictates that stored procs are the way to go. MS also has to listen to these people, and give them what they need too, so they can work with the future tools MS will release, which all will have EF support.
What the vocal group of petition signers often forget is that the group of people who have to work with corporate policies and a huge database which already exists and has to exist for years to come is massive and wont go away, even if they wanted to: their hands are tied.
Most of the vocal people in that petition signers group are consultants who have the luxury to be able to pick their projects, to demand from their temp employer to change things so they can feel at home. That's great and all, but many many people out there don't have that luxury, on the contrary.
The vocal group has some clever people among their ranks, it's just that they should be a bit more pragmatic at times. No .NET rock star developer can demand from a group of oracle DBAs sitting on terabytes of data that they'll give up their carefully crafted schema and proc set, nor will a corporation drop policies at once because some hotshot says so. It's sad, and I wished it was different as well, but it's reality.
@Roger,
I'm still holding the line that the EF v1 intrusiveness and restrictions on your domain model and TDD practice is very harmful. The second I got EF v2, I would really want to get rid of the EF v1 infrastructure noise in my domain model.
The reason I think that it'll be easier to start with NHib first, then migrate to EF v2 later is NHib's much lesser impact on your domain model classes. If you keep NHibernate infrastructure completely locked behind your Repository or base Repository class, swapping out NHibernate for EF v2 with its POCO model shouldn't really be that bad.
I still think that going from EF v1 to EF v2 POCO would be much more painful because you would have to rollback so much of the EF v1 boilerplate code that gets generated into your objects.
If you don't care about the EF v1 intrusiveness or the EF v1's negative impact on TDD practices, then you don't really care about my argument anyway.
Jeremy
Post a Comment