Databases
StackOverflow2013
Postsdbo
PO
 

Note that there are some explanatory texts on larger screens.

plurals
  1. PO
    primarykey
    data
    text
    <p>I like the stripped down display objects. It's more efficient than building the whole domain object just to display a few fields of it. I have used a similar pattern with one difference. Instead of using an edit version of a DTO, I just used the domain object in the view. It significantly reduced the work of copying data back and forth between objects. I haven't decided if I want to do that now, since I'm using the annotations for JPA and the Bean Validation Framework and mixing the annotations looks messy. But I'm not fond of using DTOs for the sole purpose of keeping domain objects out of the MVC layer. It seems like a lot of work for not much benefit. Also, it might be useful to read Fowler's take on <a href="http://martinfowler.com/bliki/AnemicDomainModel.html" rel="nofollow noreferrer">anemic objects</a>. It may not apply exactly, but it's worth thinking about.</p> <hr> <p>1st Edit: reply to below comment.</p> <p>Yes, I like to use the actual domain objects for all the pages that operate on a single object at a time: edit, view, create, etc.</p> <p>You said you are taking an existing object and copying the fields you need into a DTO and then passing the DTO as part of the model to your templating engine for a view page (or vice-versa for a create). What does that buy you? The ref to the DTO doesn't weigh any less than the ref to the full domain object, and you have all the extra attribute copying to do. There's no rule that says your templating engine has to use every method on your object.</p> <p>I would use a small partial domain object if it improves efficiency (no relationship graphs to build), especially for the results of a search. But if the object already exists don't worry about how big or complex it is when you are sticking it in the model to render a page. It doesn't move the object around in memory. It doesn't cause the templating engine stress. It just accesses the methods it needs and ignores the rest.</p> <hr> <p>2nd edit: Good point. There are situations where you would want a limited set of properties available to the view (ie. different front-end and back-end developers). I should read more carefully before replying. If I were going to do what you want I would probably put separate methods on User (or whatever class) of the form forEdit() and forDisplay(). That way you could just get User from the service layer and tell User to give you the use limited copies of itself. I think maybe that's what I was reaching for with the anemic objects comment.</p>
    singulars
    1. This table or related slice is empty.
    1. POSpring MVC: should service layer be returning operation specific DTO's?
      singulars
      1. PTQuestion
    1. PTAnswer
    1. USGMK
    1. USGMK
    plurals
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. POSpring MVC: should service layer be returning operation specific DTO's?
      singulars
      1. PTQuestion
    1. This table or related slice is empty.
    1. VO
      singulars
      1. PO
      1. This table or related slice is empty.
      1. VTUpMod
    2. VO
      singulars
      1. PO
      1. This table or related slice is empty.
      1. VTUpMod
    3. VO
      singulars
      1. PO
      1. This table or related slice is empty.
      1. VTAcceptedByOriginator
    1. COThanks for the reply. If you use the domain object for an edit operation then do you also use the domain object for a new operation and everything else, why only for an edit? In my case I am stuck with an anemic domain object, can't do anything about that. The reason for the DTO's is that my domain objects are complex with many relationships and properties that I dont need for my views.
      singulars
      1. PO
      1. USarrages
    2. COsee my comments above...
      singulars
      1. PO
      1. USGMK
    3. COThank GMK, The reason I was thinking on doing this is not becuase it's lighter on the system. I think there is a legitimate reason for what I want to do. It's true I dont have to use anything I don't need from the domain object, but using the object to get what I need can be difficult at times, there is also a security concern as the view would have access to fields it should not have, and locking down the object is probably just as much trouble.
      singulars
      1. PO
      1. USarrages
 

Querying!

 
Guidance
A row detail

Detail views are divided into sections. All the information in the data section comes from columns in the selected row. The other sections display data from other, related rows.

Related data can be related in a to-one or a to-many fashion. Captions of data related in a to-many fashion link to a list view showing a filtered view of the table.

Try moving around until you find a non-empty to-many entry and click on the label to get to one. You can move back to the root by clicking on the database name in the header.

SQuiL has stopped working due to an internal error.

If you are curious you may find further information in the browser console, which is accessible through the devtools (F12).

Reload