Is this just another OR/M framework? Yet more NIH syndrome from Microsoft.

In my lack of experience, I would say that EF is a great way to get the main anonymous developer who works 8 hours day without reading books or gets updated on PI.

The only sorrow here is the EF shortcomming, but my hope is that it will be an eyeopener to other OR/M's out there.

My hope is that MS will learn and make a kickass OR/M sooner then later.

Plz Vote against the shortcommings in release 1.0.

Benny

The OR/M you're looking for is maybe Euss by Evaluant.

MIT license. Support via Skype.

http://euss.evaluant.com

The use of an OR/M solution to Map your domain model to a Relational Persisnance model still requires a lot of development effort despite the solution, which is why I'm experimenting with db40 (db40.com) which promises to bypass this effort. Sounds good in theory, only time will tell whether it works in the real world!

What I hope this criticism from some parts of the community does not do is slow the pace of innovation from Microsoft or make their core developers angry! I'm excited about using the Entity Framework. But also about other new technologies like Silverlight. In the latter too, Microsoft have time constraints or broader architecture decisions to make that mean the perfect or complete solution doesn't come first time. But that doesn't mean they aren't great technologies that very good solutions can be built with. Entity Framework to Silverlight intergration with ADO.NET Data Services is a very well thought out practical bit of integration. Perhaps not perfect. Perhaps slightly locking one into Microsoft technologies. But very clever and very welcome. It's surely these integration aspects that mean we might have to be patient with the Entity Framework.

What makes it so?

From brief overview, doesn't seem to be unique.

I'm sorry but I don't see the point in this document.

Microsoft is a supplier of software technologies and, to my knowledge, has never claimed to be a mentor of software design and architecture. In this case MS saw a need and fulfilled it to the best of its understanding. It is left for the market to decide if it is superior to other OR/M frameworks available.

I can argue that MFC, VB6, WinForms and WebForms are all technologies that assisted organizations in shooting themselves in the head, but the truth is it is not the technology that is to blame but those who used it. Those who would use EF the way MS tutorials suggest would just as easily abuse any other OR/M framework.

I'd be interested to know on which points nHibernate fails to meet the criteria for your kick ass OR/M solution. Is it the high level of manual configuration that's needed? Or does it not count because you have contributed to the project? :)

Demis,

I am extremely sensitive to friction in development, and I am not seeing this.

Morcs,

I think it does meet my criteria.

I know that every time it doesn't I go in and make it so.

Personally, I'd rather see efforts into making NHibernate 'WCF' friendly.

ie. the ability to call repositories on a lazyload to a mapped WCF interface

Order

OrderLines

in disconnected environment the Order.OrderLines would call the OrderRepository.GetOrderLines() which is mapped to the WCF service call

Currently, I'm stuck pulling down object graphs without lazyload for disconnected WCF/Web Services

Steve,

a) exposing your model over the wire is generally a bad idea.

b) a patch is always welcome

c) leaky abstractions in a bad way

In the link, it discusses lazy load. Is lazy load always preferred?

It gives that impression.

Steve,

Implicit lazy load is critical for removing persistence concern from the code.

I'm not sure about one thing there. What is meant under:

SHARED, CANONICAL MODEL CONTRADICTS SOFTWARE BEST PRACTICES

What exactly means "Shared, Canonical Model"?

Is this a model that is shared among different applications?

If yes, it's the choice if developer to do it or not. It's not related to EF.

If no, could please somebody elaborate it.

Thanks.

I must be missing the picture totally. I thought the point of the dual mappings in EF was to further abstract the persistence from the domain model. In all honesty, I'd prefer a rich designer story in v1 followed by MS addressing gaps in functionality as opposed to a product that has been in existence for 7 years but still doesn't have a good desgner.

Plain and simple, while theorizing about the purity of a DDD is great sometimes people just want to get stuff done. Microsoft knows their primary audience, and it's not people who pontficate about this kind of stuff. Regardless, EF is going to raise the bar for the average data access code written by the average developer.

Mike,

Since NH has multiple designers in existence, I have no idea what you are talking about.

The designer is only helpful for the short time of creating stuff. It is actively harmful when maintaining the software, and it doesn't add anything when you come to use it

Like I said I didn't get the full picture but my understanding is that there are two models for EF...the Conceptual Model and the Physical Model. The physical model maps to and abstracts the database while the Conceptual model maps on top of that. In theory the dual mapping provides a buffer between your domain model and changes to the database.

I figured that one would use the partial classes for the physical model to place the data access logic. I wasn't aware that the EF wouldn't come with lazy loading out of the box...LINQ to SQL has it, I'm not sure why it didn't make the cut for EF.

When I used LINQ to SQL, I didn't just use the designer to generate the entities, I also updated, and maintained the mapping with it. If EF doesn't allow for that scenario, then that is another place it's lacking compared to LINQ to SQL.

When I talk about a designer, I mean a tool like the LINQ to SQL designer that not only generates the model one time, but also allows you to manipulate and refine the model. So it is useful beyond the generation phase of your domain model.

I haven't seen anything similar for NH. I've seen the code generators like Codus, myGeneration, et. al. But no actual designers. Granted I haven't looked hard for one in a few years, if that scenario has changed, I would love to stand corrected.

I guess what I need to do is actually explore what EF has to offer so that I can approach the conversation with more knowledge.

I apologize if my first post came across as hostile or condescending toward nHibernate. I believe it's a great tool and I'm actually looking forward to reviewing the 2.0 bits to see how far it's come since my last usage of the framework.

Keep up the great work!

--Mike

Take a look at ActiveWriter or NHibernate Addin.

The tools for EF are not usable in a team env. they are causing merge issues.

The cost of changing something there is

So we should use NHibernate because it meets your criteria of a good ORM ?

NHibernate has its own issues too.

Mark,

Did I ever denied that?

It looks like Microsoft is very interested in addressing the community's concerns. See here http://blogs.msdn.com/dsimmons/archive/2008/06/03/dp-advisory-council.aspx

And here

http://blogs.msdn.com/adonet/archive/2008/06/23/entity-framework-v2-transparency-in-the-design-process.aspx