Dan Simmons has a great write-up on Microsoft's vision of Entity Framework that really gives some insight into the motivation behind a lot of the direction that they're going in. Go read that post, and come back.
Back now? OK good. I like to pull quotes out, and I don't like to pull them out of context, so it's best to read the original post or I might seem like a bit of a tool for doing so.
The quote that showed me the direction the best was:
The EF was specifically structured to separate the process of mapping queries/shaping results from building objects and tracking changes. This makes it easier to create a conceptual model which is how you want to think about your data and then reuse that conceptual model for a number of other services besides just building objects.
The emphasis added is mine. Dan then goes on to describe the different ways you might reuse the conceptual model, from reporting, exposing RESTful services, online/offline models, etc etc.
Those are a LOT of different concerns to be talking to the same database. Although a mapping layer provides a translation, it's still talking to the same database.
My comment on his post was:
I think it's a mistake to share a data model with anyone outside your bounded context (see Evans, Domain-Driven Design). It's also a mistake to share a conceptual model or a EDM or whatever we're calling this.
I never want domain objects exposed directly via services. That's violating the encapsulation I'm trying to create.
If someone wants SSRS, then I give them a separate reporting database, tailored to reporting needs. I don't want reporting concerns bleeding into my transactional concerns. A mapping layer will not solve this problem, products like SSIS can. You want reporting? Here's your read-only view, updated every hour, five minutes, daily, whatever.
Sharing a connection string is sharing a connection string, no matter how much lipstick you put on that pig.
You'll get nothing but trouble if you share a database connection string, no matter how many layers you put between them. Because eventually, some consumer of that data will want some change in the database (not just the conceptual model). Not maybe, not in edge cases, but always.
Personally, I'd much rather go for the Domain-Driven Design style Bounded Context, where I have Anti-Corruption layers between different domains. Sure, an Order entity might have the same identity from context to context, but that doesn't mean the conceptual model stays the same.
And how would you manage and maintain those conceptual models, when so many folks might need change? You'd have to shape your organization around your conceptual models to be able to handle the feedback and change requests from the different groups using your One True Model.
The EF goal is well beyond simple ORM. It's an Object-Relational Mapper Mapper. You map your ORM to another conceptual map, which maps to the data model map, which maps to the database. The "just building objects" part tells me that EF is seriously discounting the idea of a rich domain model, which is where the heart of my business logic is.
There, and in stored procedures of course.
Posted
May 19 2008, 05:32 PM
by
bogardj