Posted in Coding, News, tagged .NET, EF on May 19, 2008|
Leave a Comment »
As the new VS2008 SP1 is coming out the door, Scott have a great post for all the improvements… One of the data development improvement is ADO.NET Entity Framework.
Danny Simmons, a Microsoft developer for ADO.NET Entity Framework project, has recently written a blog post comparing the Entity Framework with other data access solutions, which create a huge debate. I interest on how it compares with nHibernate. Here is an excerpt
The EF was specifically structured to separate the process of mapping queries/shaping results from building objects and tracking changes. This makes it easier to create a conceptual model which is how you want to think about your data and then reuse that conceptual model for a number of other services besides just building objects. Long-term we are working to build EDM awareness into a variety of other Microsoft products so that if you have an Entity Data Model, you should be able to automatically create REST-oriented web services over that model (ADO.Net Data Services aka Astoria), write reports against that model (Reporting Services), synchronize data between a server and an offline client store where the data is moved atomically as entities even if those entities draw from multiple database tables on the server, create workflows from entity-aware building blocks, etc. etc.
Dan admit that nHibernate is a rather full-featured ORM, and try to position EF to be more long team vision s for different layers or usages of the data. However, It seems that the EF team are strictly focused on data, the EF framework is very intrusive which made your application entity aware and bake its infrastructure directly into your business objects. NHibernate is not, it lets you use POCO in your business process.
I’d prefer a framework to be able to let me focus on business objects and problems, without data access infrastructure concerns bleeding into my business classes.
Greg Young, a Vancouver MVP, I met in Qcon last year, on his blog:
A single model cannot possibly be appropriate for all facets of your application including transactional behaviors, searching, and reporting. … Let me say for the 1000th time. If you are reporting off your transactional model you are seeking trouble!
…
I highly doubt a system like EF and what they suggest would work beyond trivial cases and is (as proposed) one small step up from using sprocs and linked servers as your integration model.
Jimmy Bogard, a senior consultant with Headspring Systems, had his reaction on his blog:
I think it’s a mistake to share a data model with anyone outside your bounded context (see Evans, Domain-Driven Design). It’s also a mistake to share a conceptual model or a EDM or whatever we’re calling this.
…
The EF goal is well beyond simple ORM. It’s an Object-Relational Mapper Mapper. You map your ORM to another conceptual map, which maps to the data model map, which maps to the database. The “just building objects” part tells me that EF is seriously discounting the idea of a rich domain model, which is where the heart of my business logic is.
There, and in stored procedures of course.
So far, it seems that there is lack of EF cheerleaders so far…
Read Full Post »
Archiveloper 