Automation vs Control - .Net Entity Framework 4 vs Custom Solutions

Question

I've been a heavy user of .Net since its inception, but I have avoided using any of its ORM features, regardless of flavor. I have always been skeptical of tools which abstract CRUD, binding, validation, searching, etc. Some of this skepticism comes from painful, real-world experience; the rest of it comes from the innate desire to "own" the solution and understand every part of it.

Today, I took a serious look at Entity Framework 4--I've looked before, but not quite as seriously (or perhaps with less of an open mind).

Honestly, I'm not sure what to think, though Microsoft has done an admirable job in many regards. Their implementation of expression trees and IQueryable is impressive and does an excellent job of enabling developers to use a common syntax for data and business objects.

As a software architect, I am faced with a decision. I have a powerful and stable development framework that represents 10 years worth of lessons learned and improvements. My ORM strategy is less about pure automation and more about flexibility, extensibility and performance and I am more than happy with the results. I have a philosophy, a set of patterns, and codebase that works.

But I want to improve upon that, and part of my job is to choose the right direction in which to go. My framework (and derivatives of it) have been used in some fairly substantial products, and I have a list of ideas that will improve my codebase further.

Or, I can let go of my own work, and choose the path of complete automation and (for a while) be a novice in my chosen profession while I learn new paradigms and let go of old patterns.

I can't tell if its pride or common sense that tells me I should improve upon the things that have worked for me in the past, and err on the side of flexibility.

What has been your experience in moving from custom solutions to an entity management system (.Net EF or otherwise)? Is it worth abandoning something that works? Can such a philosophy scale to the most complex of projects?

Answer 1

My opinion is: don't change. I second you on: "Some of this skepticism comes from painful, real-world experience; the rest of it comes from the innate desire to "own" the solution and understand every part of it."

Don't be tempted to think that a product must be good because it comes from a big company; the important point is not choosing a solution because of how it is made, but to choose a solution that works, and is reliable over time.

If you feel fine with your ORM, and so are your final users, then keep it going.

That said, where can I download your ORM? :)

Answer 2

As for the ORM part I would digg into nhibernate as well...

http://ayende.com/blog/archive/2010/01/05/nhibernate-vs.-entity-framework-4.0.aspx http://nhforge.org/

As an architect I always tried to do as little framework stuff as possible. From my experience: you will never beat a professional framework in the long run. There are companies and communities out there that can do this way better with more man power etc.

While doing so, we can focus more on the implemenation of business related features.

But this is just one way of doing things...

EDIT: Ever considered making the ORM open source? That way you might get a community contributing to it...

Another interesting blog to read...

http://foofish.org/blog/?p=57

Answer 3

I think you need to ask yourself what kind of product you actually need to develop.

It sounds like your ORM is perfectly good, but do your clients come to you asking for an ORM? If they do (and hey, anything's possible), then feel free to continue putting effort into improving and maintaining it. It's also probably a good learning tool; by "building your own," you will probably be able to understand why other ORMs do what they do, in a much deeper manner than other developers will.

But back to the question at hand: What kind of product do you need to build? If it's a line of business application, then building or maintaining an ORM will be a distraction from your goal, so long as there are other ORMs available, "off-the-shelf," which are "good enough." And I assure you that there are, at least today. I can appreciate that this might not have been the case when you started your project.

I suspect that you're a good bit more productive working with your own ORM then you would be with somebody else's. But I also suspect that your net effort to build the ORM and use it is substantially higher than your net effort would be to use an off-the-shelf tool. I also suspect that the code you implement for your clients will be less maintainable by third parties, unless, again, the clients have specifically requested a new ORM.

Finally, the fact that off-the-shelf ORMs don't necessarily offer all of the features you require is an opportunity, not a threat. It is interesting that the other people who replied here want to see your ORM. It suggests that there is some (unspecified) pain they are experiencing with existing ORMs. One way they could solve this pain is by using an entirely different ORM. But, I think, and even better approach would be to examine the pain point, give it a name, and propose a solution which works with existing ORMs. Your experience building your own should help you identify where existing ORMs fall short, and what can be done about it. Publicizing your own solution has some value, but not nearly as much value as showing how to solve the problem using a tool that tens or hundreds of thousands of people already use.

IQueryable, as you say, is a really interesting abstraction. It allows you to solve problems in a manner which is entirely independent of implementation. I've found it quite easy to write code which transparently supports both LINQ to SQL and the Entity Framework. I think there's a lot of value in providing such "universal" solutions.

Answer 4

I appreciate the folks who took time to answer this question, and I have left upvotes on each answer. For now, this is the approach that I have decided to take, and the people who work for me have bought into it.

Keep in mind that I lead a professional services team, so we don't often have the ability to rework old products, but we are regularly presented with the opportunity to build new projects.

Conclusions

Microsoft's Entity Framework can't be ignored, but the latest (and greatest) version is still a CTP (as far as I know). Thus, we won't jump to it just yet, but we will keep up with its progress and when we feel the time is right, we will begin incorporating it into new projects.

In the meantime, we will begin using MVC 2 (which pairs so nicely with Entity Framework) and focus on become expert in its paradigms.

We will also likely develop one more release of our own object management framework, which will allow us to learn the pros and cons of different ORM methodologies and give us ideas for how to use EF in the future (and how not to).

Lastly, while we have embraced LINQ, we have not used it to its full potential and I intend to change that. This will also be great preparation for working with Microsoft EF in the future.

Again, thank you for answering, and hope this helps someone.