BT

Facilitating the Spread of Knowledge and Innovation in Professional Software Development

Write for InfoQ

Topics

Choose your language

InfoQ Homepage News ADO.NET Entity Framework Taking Some Heat

ADO.NET Entity Framework Taking Some Heat

This item in japanese

Bookmarks

A petition has started by the community to express concerns over Microsoft's upcoming release of the ADO.NET Entity Framework.  The petition titled "ADO.NET Entity Framework Vote of No Confidence", aims to raise awareness of design and implementation issues foreseen by experts in the industry.

No Confidence

The letter is very clear in its purpose:

The signatories of this letter are unanimous in expressing concern for the welfare of software projects undertaken in the Microsoft customer community that will make use of the forthcoming ADO .NET Entity Framework.

Over the past year, Microsoft and the Entity Framework team have received a tremendous amount of feedback from experts in entity-based applications and software architectures on the .NET platform. While Microsoft’s announcement of its intention to provide framework support for entity architectures was received with enthusiasm, the Entity Framework itself has consistently proved to be cause for significant concern.

The letter appears to be well thought out and aims not to deter developers from using the ADO.NET Entity Framework but to make them aware of possible deficiencies in the current implementation:

We want the Entity Framework to be a first-rate product of the highest quality, and a tool that exceeds expectations and empowers customers and developers to create sustainable and maintainable software architectures that can withstand the pressures of software development projects of any significant size, complexity, or schedule compression.

The group feels that although Microsoft has taken their feedback during the development of the framework, that the feedback itself has not been take wholeheartedly into the version 1.0 of the product. The goal is to raise awareness of the community's concerns to Microsoft offering collaboration to help guide the development:

We collectively urge Microsoft customers to seriously consider the concerns of a group of experts that Microsoft has called, “the technical community’s best and brightest,” and who share a deep commitment to community and a willingness to help others. We have been building entity-based applications since the initial release of .NET using both Microsoft and non-Microsoft tools, and have accumulated a tremendous amount of experience in general best practices for entity-based applications as well as best practices for entity-based applications with .NET.

Because of the technical misgivings with the Entity Framework’s current design and implementation, and the potential future risk they pose to Microsoft customer projects we respectfully submit a Vote of No Confidence for the ADO .NET Entity Framework in its current state and for the on-going challenges with the expert community feedback processes.

The letter takes a stand and illustrates in detail points of concern:

  • Inordinate focus on the data aspect of entities leads to degraded entity architectures
  • Excess code needed to deal with lack of lazy loading
  • Share, canonical model contradicts software best practices
  • Lack of persistence ignorance causes business logic to be harder to read, write, and modify, causing development and maintenance costs to increase at an exaggerated rate.
  • Excessive merge conflicts with source control in team environments.

Those interested in more information can visit the home of "ADO.NET Entity Framework Vote of No Confidence" where they can also sign the letter and also see a list of those who have already signed, totaling 270 at the time of this writing.

Industry Reaction

A stand taken with such opinion does not go without criticism and response.  A search for this petition in your favorite search engine leads to results on both sides, both for and against Microsoft leading to a lot of noise. 

The ADO.NET Entity Framework team was quick to post a response the letter.  Tim Mallalieu, from the team, defends and outlines the goals of V1.0 of the Entity Framework and the future:

The unfortunate reality is that these are scenarios that we care deeply about but do not fully support in V1.0. I can go into some more detail here. One point to note is that the choices on these features were heavily considered, but we had to deal with the tension between trying to add more features vs. trying to stay true to our initial goal which was to lay the core foundation for a multiple-release strategy for building out a broader data platform offering. Today, coincidentally, marked the start of our work on the next version of the product, and we are determined to address this particular developer community in earnest while still furthering the investment in the overall data platform.

As with any version 1.0 product that not all the features a team would like to have implemented makes it into the release and need to be put off until future releases.  These features and the result of feedback is what makes version 2.0.

The ADO.NET team is taking an approach of openness going forward of their design process with the goal being as transparent as possible. 

We will follow a process similar to what you may have seen on Astoria Team blog (ADO.NET Data Services) over the past 9 months, regularly posting our design notes to the New Entity Framework Design blog and providing you with the opportunity to give feedback when we are actively discussing a certain aspect and before we have made a final decision. For more information on how this process will work, check out our first post, and expect more to come very soon!

Conclusion

The position of the group who created this letter is very clear. but it's open to who is right.  Microsoft has spent a long time in the development of the framework with very careful decisions made in the design.  There are always more than one side to any battle and the letter clearly outlines some very passionate concerns for a version 1.0 product from Microsoft. 

As with any product used by developers there are inherit risks in adoption.  This case seems to be particularly unique because of the time a group of industry experts has taken to raise awareness of potential issues before using the product.  It would be nice if all products were accompanied but such a detailed warning label. 

Maybe some or all of these concerns will make its way into a future release of the ADO.NET Entity Framework.  Microsoft has a history of putting out a 1.0 product which does not meet the needs of its audience, takes tons of feedback and gives developers a great 2.0 or 3.0 product.  This could be history repeating itself and the petition leading the way.

The letter can be read in its entirety at "ADO.NET Entity Framework Vote of No Confidence" and the detailed response to each concern outlined in the letter can be read at Tim Mallalieu's blog.

Rate this Article

Adoption
Style

Hello stranger!

You need to Register an InfoQ account or or login to post comments. But there's so much more behind being registered.

Get the most out of the InfoQ experience.

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Community comments

  • Some good, some bad

    by Francois Ward,

    Your message is awaiting moderation. Thank you for participating in the discussion.

    Some of these "demands" are definately legitimate. The source control issues, problems with canonical models, for example. Others though, like the anemic entities and the lack of lazy loadings, are things that Microsoft understood right, but many don't seem to.



    Business logic in entities, the bane of the early object oriented architectures, and lazy loading, one of the biggest performance killers and "hidden" bugs (on top of being one of the reasons a lot of DBAs will stop the development team from using ORMappers) are things that must stay out, no matter what, for the entity framework to work well. And its not like MS doesn't give you alternatives... Partial classes work amazingly well (in opposition to what these people wrote on their page, saying they're not good enough), and lazy loading is supported in LINQ to SQL. For the entity framework however, big no.


    As a general rule, what I've seen is when people see the power of lazy loading, they quickly jump in, when given the option. Then when the project is purring along, they almost all wish they hadn't. Its not obvious which issues it can and will raise later. Probably why MS took it out.


    Reminds me of LLBLGEN Pro's Self Servicing vs Adapter model. Almost everyone (back in the days at least, I haven't worked with it in years, unfortunately) would go with Self Servicing first... then in the forums you quickly saw almost all of em eventually going Adapter. It was just better for real world scenarios.

  • the bane of the early object oriented architectures

    by Jeff Santini,

    Your message is awaiting moderation. Thank you for participating in the discussion.

    If Business logic is seperated from the data, then I fail to see the OO'ness of the "early object oriented architectures". How can you have OO if you dont' want your logic to live with your data?

  • Re: the bane of the early object oriented architectures

    by Al Tenhundfeld,

    Your message is awaiting moderation. Thank you for participating in the discussion.

    Jeff, could you elaborate more on your point?



    Regarding, "want your logic to live with your data," specificity of language is important here. It certainly makes sense for data access objects to include "logic" to translate your persistence output to an instance of the data object, i.e., an object should know how to CRUD itself.



    However, it is risky to include business "logic" in your data objects. This is especially true when the logic involves the interaction of multiple types and/or can vary based on installation-specific rules. Many architects advise keeping the data objects very simple, i.e., regenerate-able, and building a layer of business objects on top of the data objects. The business objects may represent an abstracted full domain model, a lightweight presentation model, or numerous other approaches.

  • Re: the bane of the early object oriented architectures

    by George Jiang,

    Your message is awaiting moderation. Thank you for participating in the discussion.

    Domain Model vs Table Module vs Transaction Script, back to 2002?

  • Re: the bane of the early object oriented architectures

    by Brett Huber,

    Your message is awaiting moderation. Thank you for participating in the discussion.

    Microsoft and its development community seem have never truly understood what “separation of concerns” means. Most of their architects and developers are still proud of pulling data using DataReader, DataSet or Typed DataSet, massaging them using business rules and binding them to Controls. MVC, O/R Mapping, and Domain Model, those are almost common sense to Java and other communities, are very foreign to most of them.

    Not long ago, I went to a Microsoft sponsored seminar. A guru, who has published a few .NET books, a Microsoft MVP/Legend, still questioned the merits of multi-tiered architecture by arguing companies hardly change the database after project being released. He forgot at least one thing: Microsoft has changed the database technologies many times during last decade or so, from ODBC, OLE DB, RDO, ADO to ADO.NET. If you proliferate the data access technologies into middle tier, worse to presentation tier, you will be stuck there forever, if not spending lot money re-writing your application.

    In all, this just one again proves my view: Microsoft has never been a responsible IT citizen in enterprise application development area.

  • Re: the bane of the early object oriented architectures

    by Tamer Emin,

    Your message is awaiting moderation. Thank you for participating in the discussion.

    I totally agree with Brett Huber.

    I've noticed the same problems with applications I've supported (repaired) over the years.

    For the stuff that I've developed from scratch, I've implemented SOC as far as possible, with very few problems that I known about.

    Unfortunately, you don't get any thanks for developing a scalable application :(

    Tam

  • Re: the bane of the early object oriented architectures

    by Fakher Halim,

    Your message is awaiting moderation. Thank you for participating in the discussion.

    "How can you have OO if you dont' want your logic to live with your data?"---

    The answer is in having multiple logics (Views/Classes) without altering the database schema. That is what Entity Framework does.
    For a simple example, you may visit:www.codeproject.com/KB/architecture/LinqEntityF...

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

BT