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

Jeffrey Palermo (.com)

Blog moved to www.jeffreypalermo.com

Linq to Entities: Microsoft's first go at O/R Mapping (they need our feedback now!) - level 300

First, none of this is NDA.  Others discussing it are Ayende and Sam.   Here's a quick rundown of how you would get Linq to entities working:

  • Create the metadata file using the wizard.
  • Select some database tables to map to objects.
    • Wait for the designer to generate the mapping meta data.
    • Wait for the designer to generate some partial classes that might serve as entity objects.
  • Add code to these new classes to do interesting things within your domain.
  • Using Linq queries to work with these objects and watch the SQL be generated and sent to the database.

This sounds easy  when you remember that the designer is generating all the ugly goo that _has_ to be there.  First, the classes must inherit from the mapping base class.  They are working on a way to make it implement an interface instead.  This is a non-starter first of all because it would require the domain assembly to carry around a reference to a data access dependency.  Next, for dirty-tracking, each property mutator must raise an event to let the framework know that a property changed.  Every property.  Let me repeat:  Every property setter must raise an event for dirty tracking to work.  This is another non-starter.  The team plans to have all this generated for you in partial classes. 

I have email addresses for several people on the team, and I'll be letting them know what is so compelling about NHibernate and why the above issues have to be resolved before RTM and not after.

In some cases, you don't care if the classes are data-transfer objects instead of domain objects.  In that case, use Linq to SQL, not Linq for Entities.  With Linq to SQL, you can use DTOs all over the place and work with the data pretty easily.  Heck, you could even use Linq to SQL to create your own data layer for hydrating your domain objects manually from the DTOs you decorate with the Linq to SQL attributes.

Linq to Entities is a different animal and is meant to persist domain objects.  Domain objects ARE the most important part of the application.  The domain defines the business problem scope.  Persisting to a data store is secondary to the domain model's structure and behavior. 

I want Linq to Entities to succeed.  I want frameworks and tools to continually get better; therefore, I will be communicating with the product team to voice my strong concerns over the current direction.



Comments

Ayende Rahien said:

@Jeffery,

I am finding it hard to get publicly available information about EF.

Can you point me to some sources?

# March 15, 2007 2:15 AM

Ayende Rahien said:

I am sorry, I know all of that, and I already have the CTP.

What I am interested in is stuff beyond the very high level overview + maybe hello world.

# March 15, 2007 5:27 AM

sergiopereira said:

@Ayende, I've trying to get on top of that too and I have been collecting some links. Maybe you can find one that you haven't seen yet over here: http://del.icio.us/sergiopereira/entityframework

# March 15, 2007 7:48 AM

Scott said:

This is their second foray into this realm (remember ObjectSpaces?). It looks like the designer for this is different. My big question is: What's the ROI look like vs. using NHibernate/WilsonORMapper/LLBGen/Gentle.net?

# March 15, 2007 9:05 AM

Jeffrey Palermo said:

I don't think there is any documentation yet, just the bits.  I spoke with the Entity Framework architects today, and the roadmap is actually quite bright, so I'm less concerned now.  I think they are on the right track, but it will take a while, so don't expect to have your domain-centric O/R mapper in Orcas.  I'm not sure what I can disclose, but I'll find out and blog an update.

# March 16, 2007 2:24 AM

Sam Gentile said:

Yup, I'm still stuck in Seattle and I still feel like crap. Tomas just went off to the airport and I

# March 17, 2007 9:02 PM

Angel Saenz-Badillos said:

Ayende,

"I am finding it hard to get publicly available information about EF"

Interesting comment, I would like to know what you feel is missing from the EF message.  Our blog at http://blogs.msdn.com/adonet/default.aspx is fairly active, if you don't see something that interests you feel free to post a comment there

# March 19, 2007 6:45 PM

ScottBellware said:

> it would require the domain assembly to carry around a reference to a data

> access dependency

Jeffrey,

This isn't really a problem unless you've got a constraint that doesn't allow you to distribute the domain object component with the data access component, or a constraint that suggests that it's inappropriate to do so.  Most web apps don't have this constraint, but many distributed smart client apps would.

Components are only units of distribution.  The only real force dictating their shapes is the app's distribution model.

# March 21, 2007 11:12 PM

system.data.objects dev guy said:

I've promised to write more about persistence ignorance in the Entity Framework, and while waiting for

# March 27, 2007 10:33 PM

Colin Jack said:

Yikes. Deriving from a few interfaces isn't the end of the world, not great but we could do it, but the properties bit is just awful. If its auto generated then it is not so bad but still....

# May 22, 2007 3:32 AM

About Jeffrey Palermo

Jeffrey Palermo is a software management consultant and the CTO of Headspring Systems in Austin, TX. Jeffrey specializes in Agile coaching and helps companies double the productivity of software teams. Jeffrey is an MCSD.Net , Microsoft MVP, Certified Scrummaster, Austin .Net User Group leader, AgileAustin board member, INETA speaker, INETA Membership Mentor, Christian, husband, father, motorcyclist, Eagle Scout, U.S. Army Veteran, and Texas A&M University graduate. Check out Devlicio.us!

This Blog

Syndication

News

Headspring Systems

View Jeffrey Palermo's profile on LinkedIn

See my new blog at .jeffreypalermo.com