I spent some time this week with Scott Bellware. He and Greg Young have been in town talking to the EF team about Test Driven Development, Behavioral Driven Design and Domain Driven Design.
On Tuesday night we went out to dinner and had a long chat. Despite the desire on both of our parts to insult each other every few minutes, I think the conversation was largely productive. The events of the evening plus my preparation for the Advisory Council made me think about going into some more detail around the EF, where we are today, where we want to go and rationale therein.
This is not intended to be "spin" - a word I have heard a lot recently. This is the opinion of a PM on the team that has been at this since pretty much the beginning.
Back to the point of this post:
We did not set out to build the NHibernate compete product in V1.0.
We did not set out to build the NHibernate compete product in V1.0.
We did set out to execute on the first part of a longer term strategy around the EDM and the set of services that could be delivered therein. ORM happens to be one of the scenarios and the one that you tend to most closely approximate as you build out the foundation.
One of the major points that Scott repeated at dinner was that he and his compatriots feel that people would just blindly adopt the EF because it was a part of the Framework and that this would set them back because they have moved on with their approach to software development and the EF does not meet their requirements. Having the EF in the market creates noise for them because it becomes a technology choice between a Microsoft product that does not yet address this school of software development and open source solutions that do.
There are schools of software development that will do just fine with the EF. There are others where the approaches at hand would require developers to compromise their abstractions and their approaches. People should just be intentional and not try to use the EF as a wonder hammer to hit all potential projects. As with any other technology, it should be evaluated in the context of the project constraints and attributes.
I shall attempt to make a series of posts leading up to and following the advisory council where I go into a bit of the history and future. This will not yield a decision matrix for a developer but it may be interesting for folks.
PingBack from http://wordnew.acne-reveiw.info/?p=10155
Thank you for this explanation - it is valid and it makes sense. Just curious, what school of software development did you target for v1? Or, if that is an unacceptable question, what school of software development would benefit from its usage? I am asking because I am unfamiliar with terms the different schools (in line with Fowler's article), not because I am trying to be combative or assert that one school is "better" than another.
"People should just be intentional and not try to use the EF as a wonder hammer to hit all potential projects. As with any other technology, it should be evaluated in the context of the project constraints and attributes."
In the field, many Microsoft customers don't evaluate technology in any context other than whether or not it is a Microsoft product. Because most Microsoft products have an implicit prescriptive approach and school of development, many Microsoft customers are not even aware of the arbitrary nature of the approach they are using.
EF will drive ORM to a level of adoption in the Microsoft community that it already has in other communities. It will do so not because it is the best solution based on context and schools of development, but because it has the Microsoft logo.
I believe, as I mentioned to Danny last week, that it is incumbent upon you and the EF team to begin work diligently to dismantle the hysteria that will drive Microsoft customers to EF by default rather than to a consideration of ORM and a further assessment of the breadth considerations that inform a decision on which framework to use, and the opportunities that each inherently opens a development organization to.
Just saying that it's necessary to assess the appropriate tools doesn't necessarily make it happen. There is tremendous momentum built up in the Microsoft customer community fed by a decade-old predisposition to fear, uncertainty, and doubt that first needs to be overcome.
You and the team are in a unique position here to bring some rationality to customers' deliberations as they assess ORM and its approaches and schools.
Your words are spot-on, and I'm hoping that they will be bolstered with actions that help ease the context that keeps them from being put into tangible and meaningful practice in the Microsoft customer community.
Not to belabor the point, but the EF v1 bashing isn't because it's not "NHibernate Feature Complete." The "vote of no confidence" criticism is directly aimed at the usability of the EF, not the feature list. You had choices to make about how you implemented change tracking, lazy loading, and entity references. I think you guys made some less than desirable choices in how you implemented the features that were delivered, and hence my signature on the VONC document.
For V2, don't treat it like a "I must do every possible thing that NHib, LBLLGen, SubSonic, etc. does" for parity. I'd rather you put the focus on making EF V2 more usable with the features you've already got.
Message received. We understand the feedback. This post was more about telling people to be intentional about their technology choice.
We are taking a hard look at all of the areas that you mentioned - usability is paramount, as is an attempt to make certain aspects of the API consistent with expectations of different developer audiences. This investment must still be balanced with the long term data platform investment but I expect that there will be solid strides in V2.
Hopefully as I work on the next few posts it will be more clear on what we are laying the foundation for, what segments we spoke to initially and what kinds of folks are using the stack today.
To be clear, just as Jeremy and Scott have valid points about areas we can improve, there are a lot of people finding value with the stack as it is.
I have not used EF and have only a passing familiarity with NHibernate. I am not heavily invested in the outcome of this debate. I am, however, invested in the debate itself, since how Microsoft responds to feedback from the community directly affects me.
The signatories to the vote of no confidence have specific things that they care about that they believe make EF inadequate for use in V1. It is not just a matter of EF being less complete than NHibernate; the vote of no confidence is basically saying that EF is not ready to be used in production applications, because of its lack of key features.
Your response, and the general response of the EF team, is that EF V1 is not targeting people like Scott and Jeremy and the values that they believe are important; but rather, it is targeting a different group of people, trying to solve a different class of problems using different core values. I can understand that; as a developer I have had to make that same decision many times. You can't do everything you would like to do in the first pass.
What bothers me is that I can't find anything that tells me what EF V1 *is* targeting. If POCO support, lazy loading, behavioral objects, and PI were not the values that you were working from, what values WERE you working from? If people like Scott and Jeremy are not your initial target audience, who is? The signatories to the vote of no confidence believe that EF is not ready to help them solve their problems; what problems is it ready to solve? I think if the EF team could be more transparent about these issues, it would go a long way towards swaying those of us who are "on the fence". Your explanation may not satisfy Scott or Jeremy, but it would help the rest of us understand where you think EF fits in the landscape today.
If this explanation already exists and I have missed it, I apologize, and would it appreciate it if you could point me in the right direction.
EntityClient Entity Framework != O/RM Sappiamo tutti che il buon vecchio pattern in un ADO.NET Data Provider