Announcement Announcement Module
No announcement yet.
Service layer/DTO question Page Title Module
Move Remove Collapse
Conversation Detail Module
  • Filter
  • Time
  • Show
Clear All
new posts

  • Service layer/DTO question

    1. Does the @Service layer know about DTO's (can on of its methods return it or take it as an argument)?If not, that which layer know about them?
    2. Is the form backing object considered to be a DTO?
    3. Can @Controller layer create Domain objects (for example crate a new Domain object from the data provided in the form backing object)?

    Please do help me understand this, as I asked many people, and nobody seems to have a clear answer.

  • #2
    1) Why not... It is just an java class return/create whatever you like
    2) It depends on your project it can be but it doesn't have to be.
    3) Again why not, although why would your formBackingObject be something different then your actual domain object?


    • #3
      The reason I asked this question is that a while ago I read this post :
      and specifically this
      Never pass Command objects to a business service!
      This is why I would like to know if backing objects(presentation-tier-specific) can be considered to be DTO's.
      Looking at your previous post I understand that It is perfectly valid for my @Service layer to have a method that can convert my domain object to a DTO (i.e. Article to ArticleDTO or visa versa....that can be used by....umm.....lets say DWR for example), and looking back at constv's post he says that it isn't valid for my @Service method to know about commandObject (which can be a DTO too).

      To sum up:
      a)DTO's can be part of my domain model,@Service layer knows about them
      b)Command objects are presentation-tier-specific, and @Service layer doesn't know about them.
      So my question is : how is the command object any different than a regular DTO , they both are used to transfer data ( command object transfers it to the jsp(view) and back from the form);
      Last edited by yarco; Jun 13th, 2009, 02:34 PM.


      • #4
        The command object doesn't have to be presentation-tier-specific object that is where your logic is flawed. You can perfectly use your domain objects as command objects. You don't have to have a seperate object for that...

        Also you don't have to have DTO's (however it depends on your architecture) if you already use DTO's then simply use ther DTO's as command objects why create another layer which you need to maintain?????


        • #5
          thanks for the reply,
          yes we try to use domain objects as command objects too. This is certainly easier!
          Anyway now I understood that my @Service layer knows about DTO's, and can have methods to convert to/from regular domain object.
          In spring mvc, when would it be appropriate to use DTO's instead of domain objects. can anybody give a small example please. thank you so much


          • #6
            I tend to use DTO or specific command classes when there is a mismatch in what you try to do in yuor view and with your domain model. (Just like you have a relation database and OO design mismatch!). Then sometimes it can be easier to create dedicated objects. But I always would strive for as much reuse as possible.


            • #7
              If your architecture is runnable on a single vm (you don't for example EJB) I think that you would benefit a lot removing the DTO stuff as Marten tell you.

              But, if you need the DTO and that copy to/from trick you should take a look to


              • #8
                On the same lines ...

                I am using my command object in all three layers i.e. it is the commandClass for the controller, it is passed to the service layer which in turn passes it to the DAO.. and back again the same way in case of data retrieval.

                So as per the above discussion is this approach correct? Below is an example :

                I have a user registration module where the user enters his details. all of these details are mapped to the User command object which the service layer accepts adds some encrypting to the password and passes it to the UserDAO. Now, the registration form also has an additional field called 'confirm password' which is only used in the controller-validator bit and is of no use any further. so i just added an extra String field in the User command class called confirmPassword. Is this a fair thing to do? I have a code review in a couple of days and if I am asked why I do not have a UserRegistrationCommand class and a separate User DTO, my argument is going to be 1) code reuse,. 2) saving up on the conversion time from Command to DTO.

                What are your thoughts on this?


                • #9
                  this helped me out, and will help you!


                  • #10
                    Originally posted by yarco View Post
                    this helped me out, and will help you!
                    I would like to add a quick clarification to the discussion that yarco refers to - along the lines of what Marten has already said in this thread. It is absolutely ok to use original domain entities as "command objects" - if appropriate/convenient, e.g. when the submitted form's fields easily map to an existing generic domain entity's properties. In such cases, the domain object can be passed between all tiers, and no architectural principles are violated. If, however, it is more appropriate/convenient to use a presentation-tier specific "form object", a.k.a. "command object" that is not part of a generic Domain, then the data from such presentation-tier object must first be placed into a tier-agnostic Domain entity before being passed to other tiers, e.g service layer. The reason for this is that your service tier must no absolutely nothing about the implementation details of your presentation tier. You need to always think larger than one single application that you are currently working on. If you tie your service layer to a particular PT implementation, you will never be able to reuse it in another application, another portlet within a portal, etc. That would be silly and short-sighted. So, A Domain model is a generic, tier-agnostic, and preferably, application-agnostic concept. It must not contain any notion of "presentation" or "data access management". In a good architecture, that is.

                    As for pure DTOs, I almost never use them myself. If I need a lightweight object in the presentation-tier to pass between the controller and the form, I create form-specific command objects. When I need to pass something to or from a service, it is usually domain entities.


                    • #11
                      Command objects has validation JSR 303 annotations but model objects may not.

                      For Create, Update like operations
                      View --(Command)--> Controller --(Model)--> Service --(Model)--> Repository

                      For List, Show like Operations
                      Repository --(Model)--> Service --(Model)--> Controller --(DTO)--> View