Loading ...
Sorry, an error occurred while loading the content.
 

Listing Domain Objects in the UI

Expand Messages
  • Jesse Napier
    I am building a web app that displays various grids of data to users. Same of the display data may even be in tree format. This data relates to Domain
    Message 1 of 35 , Jul 7, 2006

      I am building a web app that displays various grids of data to users.  Same of the display data may even be in tree format.  This data relates to Domain Objects, but I am timid about pulling the complete object graphs down to the UI layer. For example, in one section I display an organization tree.  All I need are the Id and name of the organization; I do not need a full graph of Organization objects.  And then if an Organization is clicked on, the application will display a pageable list of jobs for that organization.  Again, I do not need a full collection of Job objects. Also, It seems very akward to pass UI paging info to repositories when retrieving pageable lists of objects. Then there are times when I get lists of data for combo boxes.  It seems completely overkill to get a list of User objects when all I want to do is display their names in a combo box.

       

      Is this type of display data considered data reporting? Should I have my application layer return DTOs for display data?  Or should I still be returning full domain objects even when just listing data?

       

      I have struggled over this in past projects as well.  As I start this new project, I am hoping to get a better grasp of this and have a happy medium between performance and a solid domain model.

       

      How are others dealing with these types of problems? 

    • Jesse Napier
      Hi Jonathan, I guess I was misleading by saying UI Layer . It s not that I don t want the UI layer to have access to the domain. This was more of a
      Message 35 of 35 , Jul 10, 2006

        Hi Jonathan,

        I guess I was misleading by saying “UI Layer”.  It’s not that I don’t want the UI layer to have access to the domain.  This was more of a performance related question having to do with read-only data that would be used for presentation purposes.  Yes the presenter could query for domain objects and then pull the relevant pieces out of the domain objects to send back to the UI, but that’s not really saving anything because the presenter still queried for a domain objects and possibly walked the object graph of each object.  I’m trying to avoid that.  If I use lazy loading then I could potentially have a large amount of db hits when walking an object graph for displaying a simple list of data.  If I know that I need the data upfront then I guess I could eager fetch the data, but it doesn’t seem right to pass fetching parameters to my repositories. 

         

        Im just thinking that displaying lists of data in a UI seems like a reporting function of the application.  If we were to create an actual report with reporting components, we wouldn’t use the domain model would we?

         

        Jesse

         


        From: domaindrivendesign@yahoogroups.com [mailto: domaindrivendesign@yahoogroups.com ] On Behalf Of Jonathan Harley
        Sent: Sunday, July 09, 2006 11:57 PM
        To: domaindrivendesign@yahoogroups.com
        Subject: Re: [domaindrivendesign] Listing Domain Objects in the UI

         

        Hey Jesse,

         

        Sorry I misunderstood you, but the point of the MVP is to separate the UI from the domain, to wit:

         

        "This data relates to Domain Objects, but I am timid about pulling the complete object graphs down to the UI layer"

         

        So, your Presenter can extract the information that is required for the UI -- however much you need and however you need it organized.  Whether you lazy load or not is determined by the depth of the graph you need to satisfy your UI.

         

        If your organization tree needs only the name and a link to more data, then you can construct a simple data structure to pass to the UI.  Is that a DTO?  It doesn't match my definition, but you may disagree.

         

        Good luck - Jonathan

         

        On 7/10/06, Jesse Napier <jnapier@...> wrote:

        Thank for the reply Jonathan, but I don't see how the Model-View-Presenter pattern answers my questions.  The presenter would still need to query for data.  I was more interested in determining if I should be querying for complete objects or partial representations of objects when I am strictly using the data for a read-only view.

         


        From: domaindrivendesign@yahoogroups.com [mailto:domaindrivendesign@yahoogroups.com] On Behalf Of Jonathan Harley
        Sent: Saturday, July 08, 2006 12:48 AM
        To: domaindrivendesign@yahoogroups.com
        Subject: Re: [domaindrivendesign] Listing Domain Objects in the UI

         

        Hey Jesse,

         

        Your instincts are on target.

         

        Use the Model-View-Presenter pattern to separate the elements of the application.

         

        You can always use some subset of data to give the View what it needs.  I like to use properties on the Page that look something like:

         

        public string FirstName

        {

            get { return FirstNameTextBox.Text; }

            set { FirstNameTextBox.Text = value; }

        }
         

        That way, the review remains essentially stateless.

         

        The button clicks call back to the Presenter where all the coordination between your domain classes and the UI.

         

        Keep the items that you send to the UI light; most of the web controls take IList for their data sources.  You can create them easily in the presenter from the domain classes.

         

        Hope this helps - Jonathan
         

        On 7/7/06, Jesse Napier < jnapier@...> wrote:

        I am building a web app that displays various grids of data to users.  Same of the display data may even be in tree format.  This data relates to Domain Objects, but I am timid about pulling the complete object graphs down to the UI layer. For example, in one section I display an organization tree.  All I need are the Id and name of the organization; I do not need a full graph of Organization objects.  And then if an Organization is clicked on, the application will display a pageable list of jobs for that organization.  Again, I do not need a full collection of Job objects. Also, It seems very akward to pass UI paging info to repositories when retrieving pageable lists of objects. Then there are times when I get lists of data for combo boxes.  It seems completely overkill to get a list of User objects when all I want to do is display their names in a combo box.

         

        Is this type of display data considered data reporting? Should I have my application layer return DTOs for display data?  Or should I still be returning full domain objects even when just listing data?

         

        I have struggled over this in past projects as well.  As I start this new project, I am hoping to get a better grasp of this and have a happy medium between performance and a solid domain model.

         

        How are others dealing with these types of problems? 




        --
        "I would rather be exposed to the inconveniences attending too much liberty than to those attending too small a degree of it." - Thomas Jefferson




        --
        "I would rather be exposed to the inconveniences attending too much liberty than to those attending too small a degree of it." - Thomas Jefferson

      Your message has been successfully submitted and would be delivered to recipients shortly.