Announcement Announcement Module
Collapse
No announcement yet.
Transfer objects? Page Title Module
Move Remove Collapse
This topic is closed
X
X
Conversation Detail Module
Collapse
  • Filter
  • Time
  • Show
Clear All
new posts

  • #16
    Additional Naming Convention...

    Originally posted by aks
    The architecture is not prescriptive that a DTO should necessary exist for every DO in the system, but it is prescriptive that a DO should never be returned from a facade or used outside a unit of work.
    I would add this point to your design:

    Don't use that "DTO" word as the suffix of your POJO. Use something meaningful. Instead of "CustomerDTO" you can use something like "CustomerVisualization" or so. This makes your "DTO" as the part of your POJO domain model.

    Check this discussion in TSS for more information:
    http://www.theserverside.com/news/th...d=34278#172706

    Lofi.
    EJOSA

    Comment


    • #17
      Don't use that "DTO" word as the suffix of your POJO. Use something meaningful. Instead of "CustomerDTO" you can use something like "CustomerVisualization" or so. This makes your "DTO" as the part of your POJO domain model.
      The "DTO" term is a legacy of EJBs, is it not? I'm all for renaming it -
      "CustomerService" has become CustomerFacade, CustomerDao has become CustomerRepository anyway.

      One of the practical difficulties I've battled with this week is to do with a "lookup" table containing attributes that the DOs need. The lookups have their own persistence lifecycle but the data is quite static. My employee table contains integer references to the lookups its stores. To create a new employee requires all the lookups to be retrieved from the repository as DTOs and passed into the constructor for the Employee DTO and then passed to the facade, to create the DO. Likewise, changes to lookup entities in the employee also need them to be retrieved and then set into the employee object. This has been a bit of a nightmare, as I could have done it using components, or even JDK5 enums. The schema is new, but was enforced by our data modeller. Maybe I'm doing it the wrong way but I can already see the benefits of using domain objects and vertical slices. I can quickly copy a slice into a new package and make modifications, and then plug in the MVC layer.

      Regards
      Alan

      Comment


      • #18
        Originally posted by aks
        The "DTO" term is a legacy of EJBs, is it not? I'm all for renaming it -
        "CustomerService" has become CustomerFacade, CustomerDao has become CustomerRepository anyway.
        I meant, just don't use those *suffixes* at all...
        - No CustomerDTO at all... no CustomerService or CustomerFacade at all
        - Instead use "real business name" something like CustomerVisualization or CustomerDetail, CustomerActivity, etc.

        Originally posted by aks
        One of the practical difficulties I've battled with this week is to do with a "lookup" table containing attributes that the DOs need. The lookups have their own persistence lifecycle but the data is quite static. My employee table contains integer references to the lookups its stores. To create a new employee requires all the lookups to be retrieved from the repository as DTOs and passed into the constructor for the Employee DTO and then passed to the facade, to create the DO. Likewise, changes to lookup entities in the employee also need them to be retrieved and then set into the employee object. This has been a bit of a nightmare, as I could have done it using components, or even JDK5 enums. The schema is new, but was enforced by our data modeller. Maybe I'm doing it the wrong way but I can already see the benefits of using domain objects and vertical slices. I can quickly copy a slice into a new package and make modifications, and then plug in the MVC layer.
        Is there any possibilities to generate those standard methods? I would take a look at AndroMDA for this stuffs (components generation, generative software development), see this thread:
        http://forum.springframework.org/sho...t=24660&page=2

        Cheers,
        Lofi.

        Comment


        • #19
          Originally posted by dewanto

          Don't use that "DTO" word as the suffix of your POJO. Use something meaningful. Instead of "CustomerDTO" you can use something like "CustomerVisualization" or so. This makes your "DTO" as the part of your POJO domain model.
          This is actually what I am doing now. As far as possible I am working directly with the domain objects. Where this is not possible I introduced new POJOs, e.g. an object called "ProjectStatistics" to hold some calculations based on the "Project" domain object. The calculations itself are performed by the business tier.

          The question that remains is where to put them. To make them part of the domain model would mean to put them in the same package as the domain objects. From the model perspective this is quite meaningful an elegant in my opinion. But on the other side this would mix persistable objects with non-persistable ones which might be confusing.

          Another idea is to put them in the package where the corresponding business tier service lies.

          Comment


          • #20
            Originally posted by dominic
            But on the other side this would mix persistable objects with non-persistable ones which might be confusing.
            I don't think it's necessarily a bad idea to have persistent and non-peristent objects in the same package. Who's to say they won't become persistent at some later stage anyway?

            Comment


            • #21
              We have developed a fairly large application with the following architecture.

              DAO -> Hibernate / JDBC
              Domain -> Business objects with data and operations
              Service -> Spring wired layer with only plumbing logic
              VO -> POJO Transfer objects, no logic
              Presentation -> Struts ActionForms, no logic

              We use Dozer framework for conversion between DO<->VO<->Form

              The application is currently 2-tiered (co-located), but will expose certain services remotely to external clients. We have exposed these services using various methods depending on usage and/or access requirements. These include SLSB Facades, JMS/MDBs and Web Services. Transactions are managed at the Service layer using Spring. Security is managed using a combination of an inhouse security framework alongwith Acegi.

              This has been working fine so far. Now, we need to deploy this in a clustered environment with WL 8.15. Please let me know if there are any specific issues that need to be addressed in the above case.

              I also request experts here to provide your valuable comments, suggestions or questions on the above architecture.

              Appu.

              Comment

              Working...
              X