Announcement Announcement Module
Collapse
No announcement yet.
Pass domain objects to presentation layer, but not to modify them? Page Title Module
Move Remove Collapse
X
Conversation Detail Module
Collapse
  • Filter
  • Time
  • Show
Clear All
new posts

  • #16
    Originally posted by debasishg View Post
    I have a slightly different view of things. I would not object to modification of domain objects by the presentation layer, so long the modification is abstracted within an appropriate service/domain layer api. The blog link posted above is the one written by me and what it discourages is exposing the implementation of the domain objects in the presentation layer. Instead of using direct setter methods like trade.setValueDate() and trade.setTradeDate(), which exposes the implementation of the domain object *Trade*, we can very well use more domain specific api s like trade.calculateValueDate(). And the domain object instance *trade* can be automagically built from http layer parameters by frameworks like Spring MVC, which will map request parameters ont POJOs that the business logic can operate on directly.
    +1. I don't see why it becomes a big issue for domain objects to be modified by the presentation tier (be it Web or rich client), so long as the actual _persistence_ is done in a controlled context, namely a transactional and secured service tier.

    And I would like to take it one step further and actually propose to see the getters and setters as actual domain interfaces on the domain model, rather than mere implementation accessors. After all, trade.setValueDate() doesn't have to always simply do "this.valueDate = valueDate". Whatever necessary domain logic for properly modifying the valueDate can and should go in there.

    Comment


    • #17
      Originally posted by karldmoore View Post
      If you ensure the only mutator methods exposed are those which *don't* bypass business logic is that OK? Is that better or worse then having a container to apply to the domain model? Who knows.
      Yeah sometimes i think leaning to a temp data container makes sense. Simple setters shouldn't be a problem i guess. But if the setters are complex then using the actual domain logic methods can lead to service layer code ending up in the presentation layer. For ex if the domain logic setter requires additional domain objects so that the value can be calculated and set properly. Then the UI layer has to look for these additional domain objects.

      Comment


      • #18
        Originally posted by manifoldronin View Post
        And I would like to take it one step further and actually propose to see the getters and setters as actual domain interfaces on the domain model, rather than mere implementation accessors. After all, trade.setValueDate() doesn't have to always simply do "this.valueDate = valueDate". Whatever necessary domain logic for properly modifying the valueDate can and should go in there.
        If I want to put more complex logic which can throw business exception in the setter, then exception handeling in the presentation layer could be a problem. (So I put some business logic in the setter, not too much)

        For example, I am using JSF, and if input fields are binding to the domain objects' properties, the setters will be invoked by JSF engine after the user sumbit the form.

        IMHO, tune the JSF engine to show error messages when the setter throws business exceptions is not a easy issue.

        Or is there any example or experience that put complex business logics in setters which could throw business exception, and successfully integreate in well known Web framework (ex: JSF, Struts, SpringMVC .... )?

        Thanks!

        Comment


        • #19
          Originally posted by manifoldronin View Post
          +1. I don't see why it becomes a big issue for domain objects to be modified by the presentation tier (be it Web or rich client), so long as the actual _persistence_ is done in a controlled context, namely a transactional and secured service tier.

          And I would like to take it one step further and actually propose to see the getters and setters as actual domain interfaces on the domain model, rather than mere implementation accessors. After all, trade.setValueDate() doesn't have to always simply do "this.valueDate = valueDate". Whatever necessary domain logic for properly modifying the valueDate can and should go in there.
          Exactly ! So long my domain level setter does not expose any implementation, I should be fine with exposing it to the presentation layer. An example will be the Order.setLineItems(List<Item> items) that I mentioned in my earler post. Here the implementation gets exposed through List<Item>, which can ideally change later. I would restrict this exposure - but should be fine with other setters as manifoldronin has mentioned.

          Cheers.
          - Debasish

          Comment


          • #20
            Originally posted by debasishg View Post
            I would love to hear what others have adopted for this type of use case. Man, I desperately miss the *best practices guide* of DDD using Spring .
            Hi guys,

            very interesting discussion: I throw my two cents.

            I mostly agree with Debasish point of view.

            When modeling a domain with Spring, by adopting the DDD practises, these are my guidelines regarding the use of domain objects (DO) into the presentation layer (PL):

            * First, I always try to directly use my DOs into the PL, avoiding DTOs or container objects representing the request data.

            * I always model my domain using *interfaces*, giving it strong behaviour through meaningful, readable, business methods, trying to limit the setters and getters to just those that actually represent business concepts, that is: setters ans getters must be there because needed by the business, not by other layers.

            * What about the binding from the PL to DOs? What if the PL needs setters and getters not in the DO? In that case, I adopt the following two strategies:
            *** Given that I always use interfaces for domain concepts, my DOs will have an interface and an implementation: so, I restrict the interface to declare only business methods, and put all additional getters and setters in the implementation. All unwanted setters and getters will not be seen by the business code (which just see interfaces), but will be actually used by the Spring binding framework: this is better explained here: http://sbtourist.blogspot.com/2006/0...rs-part-1.html
            *** Where the PL needs setters and getters that doesn't suit at all into the DO, I use AOP mixins (inter-type declaration for those AspectJ guys), for introducing additional "view" interfaces: the XT Modeling Framework (https://springmodules.dev.java.net/d...ngle/#modeling) is going towards this direction.

            That's a short summary.

            I'd like to hear other opinions.

            Cheers,

            Sergio B.

            Comment


            • #21
              I don't see why it becomes a big issue for domain objects to be modified by the presentation tier
              I don't think anyone ever said it was a problem. I think there were two issues; what kind of accessors should be exposed and ensuring that only methods which don't bypass business logic are exposed. The latter can be solved with interfaces as already pointed out.

              I like your approach Sergio and I think it makes sense. The use of interfaces as you say should make it meaningful. One slight concern I have is the number of accessors I might have to add to the domain objects. OK, fine these are only visible to some of the interfaces but does it create clutter on the domain object.

              Given the bad points of the alternatives, I'd be willing to accept the extra accessors!
              Last edited by karldmoore; Dec 12th, 2006, 03:38 AM.

              Comment

              Working...
              X