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?
I was talking to some colleagues today when the subject of 'I
could be doing something better, I can do so much more than this…' came up. Of
course we all could be doing more and better things, but sometimes we fail to
see the good around us.
I recalled something that I've read from the marvelous Argentinean
writer Jorge Luís Borges for he has a impeccable tale about this scenario.
One day in India, a superior tiger who is born, soon this
tiger is the most feared and respected of all the animals in that area and soon
he rules that domain while he is living there. Then it is captured and taken to a common zoo in Europe.
Many moons later, on a peaceful Sunday morning, Dante is at
the same zoo and see that tiger. He sees that majestic animal with so much
power and respect and it is caged for entertainment just like any regular
tiger. So he writes a poem dedicated to that tiger and adds it to the
collection called “Divine Comedy”.
Borges says: "All the power, respect and majesty of
that tiger, all the knowledge, all the fights he had during his wile life
brought it here to this specific morning at this specific zoo to be seen by
Dante and to inspire him to write an immortal poem."
I believe, just like that tiger, we all have a reason to be
something bigger than us to be here where we are today, this specific morning,
at this specific place. For this we just have to continue fighting the good
fight and soon our mission will be unveiled.