Sponsored By Aspose - File Format APIs for .NET

Aspose are the market leader of .NET APIs for file business formats – natively work with DOCX, XLSX, PPT, PDF, MSG, MPP, images formats and many more!

EF Long Term Plans

I was reading through what is actually a reasonable comparison of EF to other technologies on Dan Simmons’ blog.

Dave, Jeremy, and Jimmy have already discussed many issues but …

 

One bit caught my attention:

Long-term we are working to build EDM awareness into a variety of other Microsoft products so that if you have an Entity Data Model, you should be able to automatically create REST-oriented web services over that model (ADO.Net Data Services aka Astoria), write reports against that model (Reporting Services), synchronize data between a server and an offline client store where the data is moved atomically as entities even if those entities draw from multiple database tables on the server, create workflows from entity-aware building blocks, etc. etc.  Not only does this increase the value of the data model by allowing it to be reused for many parts of your overall solution, but it also allows us to invest more heavily in common tools which will streamline the development process, make developer learning apply to more scenarios, etc.  So the differentiator is not that the EF supports more flexible mapping than nHibernate or something like that, it’s that the EF is not just an ORM–it’s the first step in a much larger vision of an entity-aware data platform.

 

DDDD is something very similar to this but I think they have completely missed the boat. I have a single slide in my deck from devTeach that summarizes my objections quite succinctly.

 

DDDD

 

I have since rewritten this slide to be more generic in "A single model cannot possibly be appropriate for all facets of your application including transactional behaviors, searching, and reporting"

 

In DDDD I deal with this by recognizing that the Entity is of limited importance and should be different in different places … It is what happens to the entity that REALLY matters and it is the recognition and the making explicit of EVENTS in the domain that allows you to easily support multiple concurrent parallel models. These events should not be automatically generated object->field changed messages but should be DOMAIN CONCEPTS.

 

let me say for the 1000th time. If you are reporting off your transactional model you are seeking trouble!

On the DDD list people often ask "How do I use my domain to report" … the answer "You don’t" they are different models with different goals. It pains me that MS intends to push people into what is an anti-pattern, even for small systems.

 

 

Jimmy Bogard was also right on the money when he mentions that I should not expose my model outside of my Bounded Context. I highly doubt a system like EF and what they suggest would work beyond trivial cases and is (as proposed) one small step up from using sprocs and linked servers as your integration model.

 

I could say MUCH more about this but instead I will try to rework my talk a bit in Victoria Wednesday to try to include some of this.

This entry was posted in Uncategorized. Bookmark the permalink. Follow any comments here with the RSS feed for this post.

13 Responses to EF Long Term Plans

  1. Greg says:

    Larry you are right it does … I have done numerous presentations on how to handle this problem with a focus on why this problem is the most important in your domain.

  2. LarryC says:

    Based on your argument are you saying that search lists should only be retrieved from a reporting database? On a simple level these are strictly reporting views that often are not updatable other than they tend to have a key identifier that links back to records being updated.

    I would concede the point that data analysis belongs in a reporting database but I believe that “operational” reporting and live searches not only belong in the transactional model but leaving them there prevents all sorts of weird synchronization issues.

  3. 5x1llz says:

    Reading this at first felt like it was abotu to be a co-sign and I’m glad to see it’s not. Too much speculation on EF specifically for me to comment but the quote from MS in indicative of their need to please everyone and be everything to everyone. It’s not possible and ends up being overly complex and unusable. Years later it’s abandoned for the next big thing.

    What i’d love to see is a commitment from them for ONE type of mapping or translation. Keep it simple. Once released they can refactor based on the need and then respond with more specific types of translations geared at different types of models.

    I have to agree with some of the previous commenters. I was VERY skeptical about the idea that all I have to do is drop a few prtty boxes on a screen and magically generate a system.. my mother didn’t raise a fool… despite this quote I’ll still keep my eye on EF and hope they find their path over at MS.

    SMH

  4. Greg says:

    Daniel you hit the nail on the head …

    “I guess my point is that I think MS saying EF is a tool to design domain-driven frameworks that services such as reporting, querying, CRUD, etc. will”

    then

    “His phrasing in the quote is in the singular, but I took “the data model” to mean “the data models”. ”

    The *problem* is that what is being said is that its *domain driven* when its not … It is *data* driven as you later say. I think MS would be much better off if they stopped trying to sell it as domain driven (many objections would go away). When I look at it all I see is typed datasets done better, not a domain model (domain models are focused on behavior not CRUD and queries)

    “In other words, your slide and concept of exposing the domain through events would still apply, even if a system were designed using EF to develop the model(s).”

    EF tracking changes the way they do is pretty much mutually exclusive with the concept of “many models”. Since they are using object->field type changes (much like datasets do (and there is already a similar system for datasets)). I can’t always represent those changes in a parallel model since I don’t know “why” things changed (I don’t have an event just a “data update”). It fails just like hoping to do my mapping to other models with update triggers fails…

    Beyond that if you were using proper eventing you probably have no need for EF (or nhibernate for that matter).

    “His phrasing in the quote is in the singular, but I took “the data model” to mean “the data models”. ”

    I wouldn’t be so sure on this one but I would love to hear some actual clarification from them on this.

  5. Daniel says:

    “daniel, how do you synchronize between models?”
    I guess I see that as somewhat separate from the choice of an ORM tool. IMO, that would depend on factors such as the size of the data, number of reports, need for two-way or one-way sync, performance needs, etc. A simple solution if both the “business domain” and the “reporting domain” use a SQL Server data store may be DTS\SSIS. Another option would be to use the domain models themselves, and some custom process to sync. On up to olap or analysis services type solutions.

    “btw: wouldn’t just using some simple DTOs over my reporting model be much easier?”
    Maybe. It may be easier to wire your reports right up to the databases. Or it may be easier to visually design a model using some tool, such as EF =) “Easier” is a big word, and the right tool would depend on the job.

    Obviously, not having EF in production, I’m not necessarily “cheerleading” it, either. I guess my point is that I think MS saying EF is a tool to design domain-driven frameworks that services such as reporting, querying, CRUD, etc. will be able to work against- not necessarily that you will have “one model to rule them all”. In other words, your slide and concept of exposing the domain through events would still apply, even if a system were designed using EF to develop the model(s). His phrasing in the quote is in the singular, but I took “the data model” to mean “the data models”.

  6. Greg says:

    daniel, how do you synchronize between models?

    btw: wouldn’t just using some simple DTOs over my reporting model be much easier?

  7. daniel says:

    Sorry, may have accidentally posted a second ago.

    “Why are you creating a domain model for reporting?”
    Well, one reason would be to expose a model that is reusable between different reporting technologies: Reporting Services, ASP-based reports, etc. Also, to expose a layer that is more accessible for developers than SQL or wherever the reporting store is.

    “Why is it a good idea to run them both off the same back end data model?! (most likely 3rd normal form (ish) model).”
    It may or may not be. For small to medium size “forms on data” style apps, this would be fine. For larger scenarios, your data stores may well need to be separate. If you encapsulated your reporting model with a separate domain model, you’d be able (in theory) to migrate from one to multiple without changing your reports.

  8. daniel says:

    “Why are you creating a domain model for reporting?”
    Well, one reason would be to expose a model that is reusable between different reporting technologies: Reporting Services, ASP-based reports, etc. Also, to expose a layer that is more accessible than

    Why is it a good idea to run them both off the same back end data model?! (most likely 3rd normal form (ish) model).

  9. Greg says:

    Ruurd:

    “I would actually recommend to create a model per vertical slice. “

    Can you define this a bit more? This would seem to be the complete opposite of say DDD and/or the well established concepts in other communities (read: anemic domain model)

     

    Also, you mention “all of these models” how does data get interchanged between them? Is it a database “integration” model?

     

    Just on a side note, I am saying 1 model because of what the EF team wrote. You will notice that everything is discussed in the singular. Naturally noone can speak with certainty of what they are doing since as they said most of this stuff is still on the drawing boards.

  10. Greg says:

    Daniel, why are you creating a domain model for reporting?

    Why is it a good idea to run them both off the same back end data model?! (most likely 3rd normal form (ish) model).

    The data store that you create for transactional behaviors is not appropriate for reporting.

  11. Ruurd Boeke says:

    I agree.. I wouldn’t want to sound like a EF-cheerleader (as Jeremy put’s it), but I really feel like some of the critisicm I’m reading today is based on lack of knowledge of the system and the desire for lots of hits on a blog post rant.

    The conceptual model is intended to be different for different things. So, yes, it’s very easy to build a conceptual model just for reporting — it is intended to be used as such!!

    When designing a big system, which can be broken down into vertical pieces, I would actually recommend to create a model per vertical slice.

  12. daniel says:

    I don’t know that MS is saying to use the _same_ model for reporting- just that you’ll be able to use the same technology. You’ll be able to:
    -Create a domain with a “Customer”, “Order”, etc. model
    -Create a domain with a “CustomerOrderReportItem” model
    -Write application logic against the 1st
    -Write reports against the 2nd
    -Have them both work against the same data store.

    To me, that seems like a pretty good approach.

Leave a Reply

Your email address will not be published. Required fields are marked *

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>