The perfect entity model development framework
The Entity Framework is out there and it is common term already
in the framework talks. There are hundreds of sites dedicated to its
best applications and best architectures tactics.
When an architect is involved in these talks the good ones
always bring the discussion up to a helicopter view, since the discussion will
inevitably move towards the best model and to comparisons against the
'what-would-be-the-perfect'.
Now seriously, is there any perfect framework model?
The purists’ attacks against the Microsoft EF always say
that "EF is not an independent layer neither multiplatform oriented",
so it can't be reused and integrated with ease across the other systems in the
enterprise, for that would be the dreams of any architects.
Since the introduction of shared folders you could easily
for example place a text file in some URI and use it shared across many
systems. Obviously as we can see the data would not be cached and few few
mechanisms were available to raise a notification to the data holders about
that update. The EF is not supposed to accomplish that task as it is a
framework to access data using objects.
So here it comes another point: should we put a data access
layer above it?
Remember, Microsoft data access methodologies have been
changing dramatically over the last 5 years, which paves the way and gives us
hints that in a near future it will change again. Legacy systems will be always
a reality of the high paced IT market. The arguments against it is that having so many layers in an
application will over-engineer the problem and will affect the performance and
maybe the final costs rather than a simple refactoring. Remember the discussion
about table normalization and de-normalization? It is pretty much the same
here. These people are the same that advocate it is better to achieve the application's
ROI before any major refactoring. And honestly, 5 years is not enough time for many application to break even the ROI.
Here's a scenario for discussion: A programmer decides to
use EF and he maps a common class against the database. He notices that it is
very simple IF ONLY he follows 'the yellow-brick-road'. For what I have seen he must follow the EF rules;
he must inherit and implement mandatory interfaces dictated by the EF so
everything falls right in place. If not, the EF will be just one big expensive
fancy feature. Yeah, there is a term for this: Persistence Ignorant. In a
glance is like the EF do no adapt to the model, you have to make the model
adapt to the EF.
A model should be model ignorant especially nowadays where
test-driven development is becoming common in the companies. You can actually
test business rules in a higher level. That's why we start to see things like
Linq for SQL and binding interfaces. They want to cover the gap left by the persistence
ignorance.
The consequence of this is that more and more people are
using EF as a data access tool and left to using Linq in the business layer.
The business layers will then return datasets within structures called
ObjectContext. And good news, the ObjectContext is transactional meaning that
you can use System.Transaction to keep the data update rules properties. EF, Linq and ObjectContext: Is this a new
implementation being born? Only time will tell but at least they are simple to
use, have good performance and gives the programmer good deliverable
times...long gone are the days when developers wanted to stay long hours at the
office.
Strong points for the EF:
- All the query results are objects and you can parse and
traverse them in memory without any cost;
- There is an embedded conceptual layer where you can do
things like denormalize the data structure without affecting much the
application.
- Linq can be restricted to be used ONLY when needed; Linq is
great but it is no silver bullet and people are tempted to overusing it
In a way, these properties are familiar to the typed
dataset, aren't they? If you started programming with typed datasets, to
migrate to EF is almost natural and has the advantage that now you can isolate
a business logic layer with contracts. Translating: gives you scalability. Another good thing is the EF's capacity when compared
against other great frameworks like nHibernate.
But it is perfect? IMHO, it is not... and afterall, what is perfection anyway?