You've been kicked (a good thing) - Trackback from DotNetKicks.com

Oh really?  That sucks hard!  I was under the impression that you could use any object for your entities if you want and the mapping layer would be separate (just like NHibernate or Linq2Sql).  I guess I was mistaken.

It also leaves a sour taste in my mouth to read that lots of new frameworks are going to be built which automatically take advantage of EF (such as Astoria)... why can't those frameworks just use POCOs and leave it up to the developer to plug in persistence providers of their choosing?  Strange decisions

Why are we surprised that a team with a data focus has neglected to consider what the term "Entity" means in the business layer, or that the bounded contexts of data and business logic might have necessarily and advantageous differences in the definitions of terms in their dictionaries of terms?

The Entity Framework is more specifically the Data Entity Framework.  It's this distinction that shows clearly and directly that the EF team is out of its element in producing a framework for object oriented application development that makes use of a business data store.

"Entity" means something specific in a database, and is treated a specific way in that context.

"Entity" means something specific in an object-oriented program environment, and is treated a specific way in that context.

An EF "Entity" is an architectural travesty for not recognizing the difference in the contexts and the great advantages to building software with an awareness of the differences.

The EF team's persistence in refusing and recognize these basic application architectural issues raises questions of ethics for me.

In the end, the EF team operates under a safe harbor by shipping a framework that the EF hounds persist in calling an ORM, while simultaneously telling community leaders that the EF is not really an ORM in off-the-record conversations.

The EF team would be able to put themselves right back into the center line of ethics and responsibility to Microsoft customers and customer potential by stating clearly and for the record that the EF isn't really an ORM as they have said in private to insiders.

When we simply get back to seeing the EF as a pretty good query engine, we'll be able to use the tool to achieve the success that it's intended for rather than drag it into architecturally-irresponsible scenarios so as to justify the continued budgeting of the project by trumped up adoption predicated on misrepresentation.

Pingback from  The Inquisitive Coder  » Blog Archive   » Entity Framework stuff

I don't think the EF team and EF cheerleaders are the only ones guilty of this narrow focus on  data access.  

It seems that a lot places these days view the application as merely a portal through which to view the application.  Many of the contracts I work on have a mentality of "one screen - one stored proc" and treat the application as just a way to get the stuff from the database to browser (or WinForm app).  

I like NHibernate but it is somewhat intrusive with respect to the need to make public props/methods virtual in order to do proxys for lazy load.  Certainly, not as severe as DAL inheritence but still annoying.

Looks like another Entity Framework barfight! Hell, I'll join the fray started by Jeremy . I feel

Looks like another Entity Framework barfight! Hell, I'll join the fray started by Jeremy . I feel

I'm going to take a quote from Daniel Simmons on why we should use the Entity Framework . I'm

Pingback from  Dew Drop - May 20, 2008 | Alvin Ashcraft's Morning Dew

The question is this, does everybody understand the full strategy behind EDM? And would you rather have Typed DataSets as the Microsoft preferred application model of data?

The EDM and EF are separate things, the EDM is for creating models and the EF is the ORM. The architecture of EDM / EF is layered and separated in such a way that it is possible to build your own ORM above the EDM (or maybe create a NH dialect / provider).

I don't suggest that that's the first thing you should runaway and do, but this clearly shows that the intentions of the EDM is far broader then that of the EF.

A sum-up: www.lowendahl.net/showShout.aspx

cosign the need for awareness of different ways to drive out your architecture....

I personally want to use POCO's and keep them free ( by any means necessary ) of any attributes, properties e.t.c. that are solely related to data persitance. This might work if there was a seperate suite of classes altogether just designated as DTO's.

I thought the whole idea of ORM was to simplify and support OOP principles instead of sending us forwards into the past.

Patrik, thanks for that succint distinction between EDM and EF. It seems EDM will be more useful than EF especially if it allows you to (easily) map to other non-EF ORM providers.

Pingback from  Wöchentliche Rundablage: ASP.NET MVC, Silverlight 2, C#, Entity Framework, WPF, Javascript | Code-Inside Blog

Pingback from  Weekly Links: ASP.NET MVC, Silverlight 2, C#, Entity Framework, WPF, Javascript | Code-Inside Blog International

Pingback from  Weekly Links: ASP.NET MVC, Silverlight 2, C#, Entity Framework …

Pingback from  Entity Framework: Our Albatross | Developer Home

Pingback from  Entity Framework: Our Albatross | Developer Home

Pingback from  EF Long Term Plans | Developer Home

You make a great point about there being only a database centric focus.  On the other hand, this is a 1.0 release.  Great feedback and commentary from people like you may have Microsoft broadening the focus and making things more elegant in future releases.  1.0 is 1.0.

as someone who used to work on the .net team (and still remains friends) with many early .net team members, i think that the microsoft .net team has completely lost it's way.

damn near everything post 2.0 is a mess.

compare WPF to Adobe Flex/Air. WPF is a nightmare compared to the simple and easy to use Flex.

WCF is a configuration nightmare (which only eludes to the underlying overly-engineered, overly-complicated, ugly, architecture underneath). compare WCF to earlier incarnations.

WF is also a nightmare. look at the model for creating tracking services. it was literally designed backwards.

generics are awesome until you really get into the meat grinder with them and realize that the underlying subtleties weren't thought through at all.

the EF team is a joke. this reminds me a lot of the Patterns and Practices group, where they literally made up a bunch of patterns, told people that "everyone in the enterprise space is using them" and sold people into using them. subsequently, the team was gutted, and they're still trying to fix their reputation from it.

I have been toying around with EF and EM now for a couple of weeks, and found if you design your system you don't need to connect EF into your business layer.  

Simple mapping from entity to DTO and most things seem to work fine.  I think the improvements in VS 2010 ( mainly in the designer )  really enhance certain aspects for the creation.

Had previous bad experience with NH, maybe the initial project wasn't set up correctly or the database but the fact it seemed to be disappearing into a black hole for the connection bothered me.

If you ask yourself how to get the data into *your* business (POCO) object, EF4 still gives you absolutey no answer. But much worse is the fact, that you can't even get the ORM objects in your structure. Look at what EF4 calls a "ComplexType" and find out that it is a pure scalar type.

All EF4 basically does is to give you an object representation of database tables with LINQ und changetracking support. End of story.

I cant see any OR*Mapping* in EF4.

See: social.msdn.microsoft.com/.../e0092fa1-46d5-4727-ab8c-faa61cac091e