locked
Query on Entity Design RRS feed

  • Question

  • There are times when one might have to load 2 entities out of which only few fields might be required from the second entity in that particular screen. For example I could have a customer entity and an order entity. In an order capture screen I would require the order entity and few fields of the customer entity say name, address.. So the question is for a few fields of customer entity does it make sense to load the entire entity.. This would make even more cause of concern if the corresponding entity has many child entity collections in it. For example one customer would have multiple address, contact numbers and so on.

    I presonally feel that no matter who little or more one uses the entity, the entire entity needs to be loaded because it would eventually be part of the business process flow and would lead to lot of inconsistencies when entity is half field.

    Typically this issue comes up when we think of performance. I was thinking perhaps in such a scenario would lazy loading help

    Would appreciate your thoughts on the same.

    Thanks
    Sai
    Friday, January 12, 2007 6:33 PM

Answers

  • Agree with ALFKI

    Personally I think (and commented several times in this forum because this topic about efficient data modeling is definitively recurrent) that a process-driven approach could help you here. By process-driven I mean, think first on your use cases. Particularly in this one which you need to display the order and some few customer data

    Model Data Transfer Objects in order to handle the interactions between your business logic process and your data service process. As ALFKI says, if both processes are distributed, remote, model your interchanged data in order to minimize roundtrips (something like a message in - message out schema)

    Of course, achieving the right balance in terms of scalability and software simplicity isn't easy and requires experience and also courage to drop down certain barriers and, for instance, implement some data intensive logic as stored procedures in the database

    I would like to suggest you a P&P book which addresses those issues: Data Patterns (http://msdn2.microsoft.com/en-us/architecture/ms998446.aspx), its Chapter 3 has revealing guidance. Also a chapter from another P&P book: Enterprise Solution Patterns using MS .NET; I'm talking about the Data Transfer Object (DTO): http://msdn2.microsoft.com/en-us/architecture/ms978717.aspx

     

    I hope it helps

    Friday, January 12, 2007 8:53 PM
  • I don't know if you see it as clear as I do, Sai A

    Use your DTO's as your entities. Use them as a view of your logical entities. Concentrate your business logic in modeling the process (a transfer between accounts, a service cancel, a service set up, etc). Don't care so much in your logic entities bcs, in practice, there's no one-size fits all strategy with entities

    And if you start developing applications at a greater scale, the problem gets worse because you'll find that semantically related data isn't in just one place. I mean, a 360° view of the customer could need traversing thru several systems

    Just if you want to read a little more about the last, I suggest you an article of Roger Wolter: The What, Why, and How of Master Data Management. But just in case you want to read more. Don't get wrong unnecessarily if you have few time to finish your task. The bottom line is "process modeling goes first, then its <<ad hoc>> (tailored) data"

    Tuesday, January 16, 2007 4:51 PM

All replies

  • For the most part, entities are used by the user interface for two things:  single-instance creating/editing, and displaying in a list.  For editing, say a single order, I think it's perfectly fine and correct to make available (or at least lazy-load) any and all properties whether they are from the order properties itself, associations or contained collections.  The problem is in a displaying a list of many orders.  This can lead to performance problems, especially if the database is running on a separate machine.  One way to solve this is to not use actual domain entities, but simplified, denormalized, readonly "View" objects that only conatain the necessery fields to display in the list, and the ID field(s) to identify the actual domain entity that is represented.  Whether these view objects are really part of the core domain model is questionable, though, but this is a very proctical solution to a technical problem.
    Friday, January 12, 2007 8:35 PM
  • Agree with ALFKI

    Personally I think (and commented several times in this forum because this topic about efficient data modeling is definitively recurrent) that a process-driven approach could help you here. By process-driven I mean, think first on your use cases. Particularly in this one which you need to display the order and some few customer data

    Model Data Transfer Objects in order to handle the interactions between your business logic process and your data service process. As ALFKI says, if both processes are distributed, remote, model your interchanged data in order to minimize roundtrips (something like a message in - message out schema)

    Of course, achieving the right balance in terms of scalability and software simplicity isn't easy and requires experience and also courage to drop down certain barriers and, for instance, implement some data intensive logic as stored procedures in the database

    I would like to suggest you a P&P book which addresses those issues: Data Patterns (http://msdn2.microsoft.com/en-us/architecture/ms998446.aspx), its Chapter 3 has revealing guidance. Also a chapter from another P&P book: Enterprise Solution Patterns using MS .NET; I'm talking about the Data Transfer Object (DTO): http://msdn2.microsoft.com/en-us/architecture/ms978717.aspx

     

    I hope it helps

    Friday, January 12, 2007 8:53 PM
  • So can I do it this way. Typically I have scenerios wherein one entity is enough for a particular screen. Hence that entity collection gets passed as it is across layers.
    Now for scenarios wherein I need to have information from more than one entity, I make those calls to the relevant entities in the DAL, then call the assembler and pass the various entities and which in turn would return a DTO which would have a the entire mix of data from various entities and which is required by the corresponding UI.

    Am I on the right track?
    Monday, January 15, 2007 12:21 PM
  • I think that if you go the DTO route, you might as well send ONLY DTOs across the wire.  Other than that, I agree.
    Monday, January 15, 2007 3:18 PM
  • It can do a possible way, if you feel comfortable doing that (by comfortable I mean, try to simulate some interacted data changes and test how long is the impact over your code; try to answer this questions: "is it something well located in the boundaries of the layers?", "is it something which breaks my code transversally (huge impact)?")

    You can find more guidance on data modeling and data deals at the MSDN Architecture Center: http://msdn.microsoft.com/architecture/solutiones_architecture/data

     

    (PS: if you think this or any previous post answer your original question, please mark all those as useful. Thank you)

    Monday, January 15, 2007 4:53 PM
  • I am confused. If I have to send only DTO's, then there is no point of me having entities at all. cos if I load the entity and then use the same to load the DTO, I as well as load the DTO itself. If I go by that analogy then the question arises why have an entity
    Tuesday, January 16, 2007 2:11 AM
  • I don't know if you see it as clear as I do, Sai A

    Use your DTO's as your entities. Use them as a view of your logical entities. Concentrate your business logic in modeling the process (a transfer between accounts, a service cancel, a service set up, etc). Don't care so much in your logic entities bcs, in practice, there's no one-size fits all strategy with entities

    And if you start developing applications at a greater scale, the problem gets worse because you'll find that semantically related data isn't in just one place. I mean, a 360° view of the customer could need traversing thru several systems

    Just if you want to read a little more about the last, I suggest you an article of Roger Wolter: The What, Why, and How of Master Data Management. But just in case you want to read more. Don't get wrong unnecessarily if you have few time to finish your task. The bottom line is "process modeling goes first, then its <<ad hoc>> (tailored) data"

    Tuesday, January 16, 2007 4:51 PM
  • Thanks Diego. "Use your DTO's as your entities. Use them as a view of your logical entities." That statement of yours really cleared my confusion. Moreover I liked the Roger Wolter's article on MDM. I could so well relate to his statement -"While identifying master data entities is pretty straightforward, not all data that fits the definition for master data should necessarily be managed as such."

    Anyways thanks for your valuable direction.

    -Sai
    Friday, January 19, 2007 4:49 AM