The Entity Framework generates partial classes, so rather than using inheritance you can add a "GiveRaiseOf(Money amount)" method to Employee by providing the rest of the partial implementation.

This needed to be said. The "drag-and-drop domain object generator" was literally designed by the same guy who gave us the "drag-and-drop strongly-typed datasets".

I'm very weary when I see this: back in 2004, they recommended deriving business logic classes from computer-generated datasets. If history repeats itself, you will see a thousand basic examples of northwind only to discover that it scales out pitifully with any nontrivial domain complexity...

I'm not sure Billy, with generated code the partials offer a way to extend those classes without getting them overwritten.  I think it's just a fact of dealing with generated code.

A benefit would be that it's clear what is generated vs. what is specific domain logic calls.

The negative would be switching back and forth between different partials.  Obviously a best practice for me would be to logically separate the domain logic partials vs. the generated logic partials.

Actually, if you really think about it - the generated is acting like the DAL, where as the business layer partials contain true business logic.

With this, the DAL can change, you can use the UI to make changes to the generated code without necessarily breaking those business rules.

Perfect? no.  A reality of dealing with generators... probably.

Not to mention the obvious:

True DDD focuses on your domain to the point that it should be completely agnostic as to how and where it persists itself to some backend storage. This statement attacks the activerecord pattern as a whole but at least with NHibernate I have a choice as to which approach to take.

Thanks for the heads up Bill

I'm just saying that if persistence is supposed to be an afterthought, it kinda grosses me out, on an aesthetic level that my objects take a back seat to microsoft's latest persistence technology.

What if I wanted my business objects to all inherit from a common abstract ancestor? That seems like a reasonable thing to do, but I cant clearly see how to do that if I'm forced to derive from generated code.

Two words: Partial Classes

I too am going to pass on the EntityFramework, largely because I've been an NHibernate adopter for a number of years now and don't see anything in EF (planned for 1.0)  to make me abandon my existing tooling.

That being said, I think its worth keeping an eye on this thing if only b/c its going to be a 1.0 release that the EF team acknowledges is really trying to align w/ Pareto's Principle: do 20% of the work that will cover 80% of the cases.  While its true that EF 1.0 lacks any number of things that are going to be needed for it to become a real O/RM replacement technology for just about any O/RM technology with a several-year headstart (Nhib or others out there), its likely that over time this thing will begin to 'catch up' in features and become a viable alternative to those of us who build solutions 'at the edges' where we alwasy seem to hit the 20% not covered by the 80-20 rule :)

Pingback from  » Daily Bits - February 14, 2008 Alvin Ashcraft’s Daily Geek Bits: Daily links, development, gadgets and raising rugrats.

I think EF is more like the first of a series of small bridges to a true ORM. Microsoft has promoted a database first / the database is the domain model approach for a long time and while they are definately making moves to shift away from that paradigm or support parallel approaches, it will take time.

It also pays to remember that there are still a lot of .net "developers" out there who still think WebForms are the one true way and believe datasets are all you need for persistence.   Small steps is the best way to wean people off this addiction to knowing the relational model while building the domain layer.

I have introduced a first stab at easing your problem here: www.codeplex.com/efcontrib

Introduction post here: www.sitechno.com/.../IntroducingEntityFrameworkContribEasyIPocoImplementationV01.aspx

It's not persistence ignorance, but will let you get away with just creating classes and one attribute. It will then do a postcompilation to create all the goo that EF needs.

I should ask, do they support command line like sqlmetal that will put the mappings in a file like nhibernate does?

This was a common complaint with linq to sql until I found it you have the same option as you do in nhibernate.

nhibernate uses attributes or external files.  

Seems to me if you want to manually, by hand create files, then you can do that as well.

Guess we need to examine if there are command line switches with EF.

By the way, does nhibernate now support mapping one class to multiple tables?

With Ayende's latest post on Linq to NHibernate, I think NHibernate will always continue to be the extensible alternative that has a proven track record

First of all, I should say that I really appreciate this blog.

The first and major point for me is that, for the time being, EF is only targeting SQLServer. I will not consider using it (or even sample it) unless it's open to other databases.

Moreover, I Saw a presentation from Microsoft about EF during the tech days in Paris and I'm not convinced. It sounded very much like a marketing advertisement. Something useless as soon as you step out of the demo.

It's the bigger difference between open source and private worlds. Open source focus on what is usable. Companies like Microsoft focus on what they could sell (and that's perfectly normal).

I see EF as a tool I might have an eye on, but not like something I could use in my developper's daily life. At least for the moment.

Guillaume, EF is not only targeting SQL server. It has a provider model and there are lots of DB's working on implementations. Microsoft will only supply a SQL server implementation itself, and the community will do the rest. That is no different than other or-mappers. So I do not see your point.

Second, I'm working with EF a lot for EFContrib. I can say that EF is definitely up for the task. It might be less flexible in some ways than nHibernate, but it is more flexible in others.

I wish you would write comments based on actual experience, instead of a feeling you got from a presentation.

I'm sorry if you fill unconfortable with my post, but my purpose (as was M. McCafferty's if I understand well) was precisely to get feedback from people really knowing this tool, because I precisely don't. I wish I should have time to sample and make myself a precise idea, but I have not.

As an architect/developper my concern is my job's constraints against the usage and availability of technologies, not the fact that Microsoft company did or did not implement it (of course they will not provide Sybase or MYSQL implementation !).

As you know the product, I wish you would write your feelings and knowledge about this tools more precisely than "flexible", instead of judging me...

The problem with the premise in this article is that you would place behaviour into your model.  IMO a true MVC pattern (maybe implementing Dependancy Injection) is a far better approach.  In other words let the model be the model nothing more or less, and place your behaviour somewhere else.  Maybe utilise a provider pattern??

This would allow you to use entity framework as you would any other modeling system (i.e. nhibernate).

I think the argument against partial classes is a moot point. If you work in .Net technologies then you HAVE leveraged the encapsulation provided by partial classing. For example, those win form, web form and even XAML UI technologies all implement partial classes to instantiate and set properties for all the UI controls (remember -- InitializeComponent()) , while you write the "real" UI logic in a different partial class. So how is this any different? Because we are at a different layer?

I have a question concerning having behavior inside model  classes (e.g. Customer). What if we are writing a distributed application that uses WCF (hosted on IIS)? On server side it's OK. But how can we transmit this behavior to a client?

With DTO.

@Dennis, I think your question shows a potential design flaw.  Remember Service Oriented Architectures like WCF are message contract driven.  In which case you would never expect your server logic to be leveraged by the client other than through service calls.  Thus you would have to translate your EF objects into Messages that would be sent across the wire to your client.  Your client would be responsible for deserializing and transforming those messages into its own objects.  Thus the whole painful process of Database to DAL to LOB is replicated when you add services.  Now you have to go Database to DAL to LOB to Message.  Then on the client side, assuming you are also writing the client you would have to go Message to client LOB or consume the Message in other ways like jquery.

My limited experience with the Entity Framework (and Linq to Sql) is that they aren't going to compel developers to switch O/RMs. If you're already using NHibernate I don't know that you could justify switching even if EF was a comparable tool.  What I'm exploring is the possibility of replacing my old-school stored procedure-to-DataSet-to-Object-back to-stored procedure code.  I can see some value in treating the EF Entities as DTO's and mapping those to my domain objects rather than datasets/datareaders.  That approach would simplify my mapping logic (LinqToEntities-to-Entity-to-Object-to-Entity-persist) .    I'm also coming from a place where I already have a ton of domain objects that I wouldn't want to re-write as Entities and partial classes.  However, I can see the potential benefit of reducing the number of  CRUD sprocs necessary while at the same time increasing type safety.  I might feel differently if I was building my domain objects from scratch.

My limited experience with the Entity Framework (and Linq to Sql) is that they aren't going to compel developers to switch O/RMs. If you're already using NHibernate I don't know that you could justify switching even if EF was a comparable tool.  What I'm exploring is the possibility of replacing my old-school stored procedure-to-DataSet-to-Object-back to-stored procedure code.  I can see some value in treating the EF Entities as DTO's and mapping those to my domain objects rather than datasets/datareaders.  That approach would simplify my mapping logic (LinqToEntities-to-Entity-to-Object-to-Entity-persist) .    I'm also coming from a place where I already have a ton of domain objects that I wouldn't want to re-write as Entities and partial classes.  However, I can see the potential benefit of reducing the number of  CRUD sprocs necessary while at the same time increasing type safety.  I might feel differently if I was building my domain objects from scratch.