CodeBetter.Com
CodeBetter.Com
RSS 2.0 via Feedburner
           Do you Twitter? Follow us @CodeBetter

Jeremy D. Miller -- The Shade Tree Developer

Under the hood and working with .Net, TDD, Software Design, and Agile Stuff

Don't know about "CodeBetter," but I'm with Ayende

Right off the bat, the "CodeBetter" guys did not give any sort of collective "seal of approval" to the Linq to Entities Framework -- and why the hell would it matter even if we did?  I found the Entities Framework to be intriguing for its potential and underlying technical foundation, but as a usable O/R Mapping tool, I think NHibernate (especially with the new Linq query language) provides a better experience.

Here's what the "Don" of all things .Net has to say on the DNR Entity Framework episode: 

http://ayende.com/Blog/archive/2007/04/11/Comments-on-DNR-226-Entity-Framework.aspx



and my recollection of that meeting with the Entities team, including my substantial hangups with Linq to Entities:

http://codebetter.com/blogs/jeremy.miller/archive/2007/03/19/MVP-Summit-Recapped_3A00_-Linq-for-Entities_2C00_-MonoRail_2C00_-and-Shameless-Name-Dropping.aspx


and Scott too:

http://codebetter.com/blogs/scott.bellware/archive/2007/04/09/161500.aspx 

 

In the end, it may not matter what they do because NHibernate and WilsonORMapper will continue to work just fine and support the way I want to work.  And if you just want yet another "design the database schema and codegen an anemic domain model from that" tool, there's a dozen tools out there today that already work that way.



Comments

Ayende Rahien said:

I went back and listened, and you are right, 14:45

"

There is this impression that this group of people is that we completely don't get their style of working.

We don't get what they do with NHibernate, we are trying to build this other product.

The more we talk about it, at one point I stopped Jeffery Pallermo and I sat down and I talked for an hour straight, here, let me a vision for a few releases out, this is what it could be like.

And I sort of like describe it, and he is "Yeah, perfect, you got it"

# April 10, 2007 9:27 PM

Ayende Rahien said:

> why the hell would it matter even if we did?

Because I respect your opinion,

# April 10, 2007 9:32 PM

Jeremy D. Miller said:

Alright, I flew off the handle a little bit, but the Entities team focus is a little dangerously pie in the sky to me.  In terms of actually working with databases in enterprise applications, I think they're thinking much more in terms of datacentric, heavy data modeling approaches first.  DDD style programming is not their first priority right now, I'm not sure how much they're considering that style of development before and after the summit, and we definitely won't get it unless enough people tell them that they do want DDD style coding without intrusive persistence gunk getting into our business logic.

# April 10, 2007 9:44 PM

Jeremy D. Miller said:

And we still won't get the stuff we asked for until post-Orcas at the earliest anyway

# April 10, 2007 9:45 PM

jdn said:

From a perspective about as outside as you can get (I don't pretend to be at your level of expertise, or even in the same ballpark...give me a couple of years)...

'why the hell would it matter even if we did?'

Well, for better or worse, arguing over who 'started' it being unproductive and not really relevant, there is a perception that 'you guys' (for lack of a better phrase) have set yourselves up as arbiters of whether EF is up to snuff.

Yourself, Scott, etc. are incredibly proficient in blogging about EF and other things, and I think that is *great*, but it is hard to keep up with, and it is hard to keep up with what exactly you are critiquing.  Is it EF itself?  LINQ itself?  In another thread, Scott indicated that much? some? of his complaints are tooling issues.

On top of that, there are the inside jokes about '300' and fighting against the hoardes, and the one gentleman (apologies for blanking on the name) who coined the 'ALT.NET' phrase, where he quotes Emerson (he quotes Emerson for god's sake) and sets up this dichotomy of 'us who get it' against 'those who don't' (who probably smoke 'crack pipes' to use Scott's clever phrase), and....I don't care about a holy war.

As someone who has recently embraced MVP and who loves Wilson's ORMapper and got burned with ObjectSpaces...I just want to know what I should look at as the best tools to produce the code I want to produce.  

Is EF crap only if you embrace some pure TDD/DDD/DoodleDoodleDee methodology that I am probably not sophisticated enought to embrace yet?  Is it really mainly a tooling issue?

Do I have to choose sides between Miller/Bellware/Ayende vs. Daniel/Guthrie/etc.?

Can't you guys who are leaders of the industry all just get along?

# April 10, 2007 10:43 PM

Bil Simser said:

I hear ya and totally feel the same way, based on what James Kovacs, JP, and others have said and what I've seen from the team. I wish I had been there as I really don't like some of the things that EF proposes to do.

I like my domain model rich and the last thing I worry about is how I'm going to get it to and from the database. The last thing. Even after the UI. I'm 5 sprints into a business calculator tool (that calculates heat loss on a pipe, very cool domain problems) and I have pushed back on the db as much as possible. The business tells me I need it, I keep saying we need to get the domain right then worry about the mapping.

NHibernate is going to the grunt work for me, injected into a repository as an IDataProvider (with a concrete NHibernateDataProvider). My mocks are happy and humming along and my FIT tests are screaming without worrying about a database. EF with it's data-heavy view of the world just messes up my way of thinking when I write quality code. The entity tracking is just plain ugly. I spent the better part of my last sprint sprinkling audit log messages throughout my domain because I can't figure out how to track the calculation another way (but I'm looking towards an AOP solution that might make this cleaner). I've also got binding lists built in my views using decorators to pull the values in from my domain via my presenter. That's where I have INotifyPropertyChanged and IErrorSomethingOrOther implemented, not in my domain. For me I try to keep my domain stateless, even if I have a Smart Client because it just feels better to manage.

So all the stuff they plan on building just doesn't sit well with me and I feel like I'm going to pollute my domain with a framework that is equivalent to MFC for Domains. No thanks. I'll stick with NHib, DDD, and TDD for now.

# April 10, 2007 10:44 PM

Leave a Comment

(required)  
(optional)
(required)  

Enter the numbers above:
Add

About Jeremy D. Miller

Jeremy began his IT career writing "Shadow IT" applications to automate his engineering documentation, then wandered into software development because it looked like more fun. Jeremy previously worked as a systems architect building mission critical supply chain software for a Fortune 100 company and learned agile development practices as a .Net consultant at ThoughtWorks, one of the pioneers of agile development. Jeremy is the author of the open source StructureMap (http://structuremap.sourceforge.net) tool for Dependency Injection with .Net and the forthcoming StoryTeller (http://storyteller.tigris.org) tool for supercharged FIT testing in .Net. Jeremy's thoughts on just about everything software related can be found on his weblog "The Shade Tree Developer" at http://codebetter.com/blogs/jeremy.miller, part of the popular CodeBetter site. Jeremy is a Microsoft MVP for C#. Check out Devlicio.us!

This Blog

Syndication

News

All opinions expressed here constitute my (Jeremy D. Miller's) personal opinion, and do not necessarily represent the opinion of any other organization or person, including (but not limited to) my fellow employees, my employer, its clients or their agents.

About Me

"Best Of" Compendium

StructureMap (Dependency Injection for .Net)

StoryTeller (Supercharged Fit)

Build your own Cab

TestDriven

MVP