Announcement Announcement Module
Collapse
No announcement yet.
Remoting and Anemic Anti Pattern Page Title Module
Move Remove Collapse
X
Conversation Detail Module
Collapse
  • Filter
  • Time
  • Show
Clear All
new posts

  • Remoting and Anemic Anti Pattern

    Hi
    Would appreciate any feedback / recommendations regarding our current application architecture.

    Broadly, it is currently as follows:

    Client: (Access to Service Layer is controlled through Spring)
    Swing Rich Client (JGoodies, JForm Designer...)
    Spring HTTP Remoting communicating with..

    App Server: (All objects on the server are controlled through Spring)
    Service Layer Pattern using....
    Data Access Objects using ...
    Toplink ORM to map to legacy database.

    State only exists on the Client.

    Currently, we have a Business Domain, instances of which exist on the Client and on the Server (but only for the lifetime of a partilcuar remote call).

    We believe that this Business Domain, shows all the features of an anemic domain model (http://www.martinfowler.com/bliki/An...mainModel.html) due to the use of remoting and the service layer to execute business logic and provide CRUD opertations on the persistent data store.

    As part of refactoring this Business Domain (it also currently too closely resembles the legacy database) I am proposing to combine the calls to the service layer within the Business Domain.

    For example, we currently have a Client Object. To "getAddresses" we call the ClientSO.getAddresses and populate the "address" property within the Client Object.

    I now intend to to implement the call to the ClientSO.getAddresses method, within the Business Domain, Client.getAddresses method.

    Does this appear to be a correct thing to do?
    Also, is it worth implementing the new features withing Spring 2.0, to use AspectJ to dependency inject domain objects.

    Any feedback greatly appreciated.

    Regards
    Marc

  • #2
    My personal opinion is that Domain Objects (even not Anemic ones) shouldn't be distributed to the client. It tightly couples the client to the server and it could give serious issues with the amount of data being transfered.

    I would use DTO's instead. With DTO's you know exactly what data is going to be transfered and it also loosens the coupling between client en server.
    Last edited by Alarmnummer; Jun 19th, 2006, 07:25 AM.

    Comment


    • #3
      The problem with Rich Domains, is how to handle serialization . You need somehow to inject repositories,etc. there. One solution is to make it with AspectJ on getter call, so they will be available after deserializing.
      But I prefer for now to use DTO(Value Objects) when dealing with remote services.

      Comment


      • #4
        Remoting and Anemic Anti Pattern

        I certainly aggree that the use of DTOs is applicable in most remoting scenarios. However, I still (currently ) believe that in our particular proposed architecture, the actual Domain Objects are more useful and can be transferred using our particular remoting choice (HTTPInvoker).

        Our app server layer is intended to be stateless, and elements of the Business Domain only exist for the lifecyle of a particular operation against the persistence layer (Spring POJOs/DAOs/ORM/RDBMS).

        State does exist on the client (a Rich Swing app), and I therefore want to make use of our hopefully rich Domain Model, without the need to retrieve DTOs, and then instantiate richer Domain Objects from these.

        Currently, I'm considering if this can be achieved by using the new AspectJ integration in 2.0 exactly as you say. In effect, I think that the Business Domain exists as a stripe across all architectural layers of the system, and Spring Aspects / DI will specify how the request for Aggregates are fulfilled, dependent on whether the objects is being instantiated on the client (though constructor) or app server (via ORM).

        Also, thinking that Aggregates (as defined within Domain Driven Design) should be used in order to set the boundaries where services are used to access or persist the objects via the application server.

        The major struggle I have is to merge the Business Domain, and our current Service Layer, to avoid our currently anemic model. Not so worried about coupling between client and server as we are in control of both, but certainly would be if we were not.

        Appreciate any thoughts, particularly if strong disagreement!

        Marc

        Comment


        • #5
          Originally posted by Alarmnummer
          My personal opinion is that Domain Objects (even not Anemic ones) shouldn't be distributed to the client. It tightly couples the client to the server and it could give serious issues with the amount of data being transfered.

          I would use DTO's instead. With DTO's you know exactly what data is going to be transfered and it also loosens the coupling between client en server.
          I fail to see how domain objects would couple the client to the server any more tightly than DTO's would. After all, most DTO's are basically "behaviorless" replica of corresponding DO's, aren't they?

          Of course the client would couple more tightly to the Domain Model, but that should be a good thing IMHO.

          Comment


          • #6
            Originally posted by manifoldronin
            I fail to see how domain objects would couple the client to the server any more tightly than DTO's would.
            If you don't use DTO's, every change in the DO, will be visible in the client -> tight coupling. If you use DTO's, not all changes have to lead to a change in the client. What if you rename a field? Add a field? Rename the class? This doesn't have to lead to a change in the DTO and in turn won't lead to a change in the client -> loose coupling.

            After all, most DTO's are basically "behaviorless" replica of corresponding DO's, aren't they?
            even if they were, I don't like tight coupling.

            Of course the client would couple more tightly to the Domain Model, but that should be a good thing IMHO.
            Why is this a good thing? If I expose my domain objects directly by a webservice for example, and I decide to rename a field, all clients need to be changed. Why is this a good thing?

            Comment


            • #7
              Originally posted by baronludwig
              I certainly aggree that the use of DTOs is applicable in most remoting scenarios. However, I still (currently ) believe that in our particular proposed architecture, the actual Domain Objects are more useful and can be transferred using our particular remoting choice (HTTPInvoker).
              Why are they more usefull? And exposing domain objects directly can lead to serious problems like security or ignoring class invariants.

              Our app server layer is intended to be stateless, and elements of the Business Domain only exist for the lifecyle of a particular operation against the persistence layer (Spring POJOs/DAOs/ORM/RDBMS).
              I don't see why this is important for this discussion (it is the way I like to write my applications also btw

              State does exist on the client (a Rich Swing app), and I therefore want to make use of our hopefully rich Domain Model, without the need to retrieve DTOs, and then instantiate richer Domain Objects from these.
              DTO's are more work than exposing DO directly. But I still prefer using DTO's because it decouples the client from the server, makes it easier to send the right information to the client (with a DTO you have perfect control on what is and isn't send) and the 'saveOrUpdate' method on the server could lead to serious problems like security and ignoring class invariants.
              Last edited by Alarmnummer; Jun 21st, 2006, 01:58 AM.

              Comment


              • #8
                Remoting and Anemic Anti Pattern

                Many thanks for the replies. I'm having some trouble organising my thoughts, so apologies for this reading like a brain dump, rather than a considered position!
                Originally posted by baronludwig
                I certainly aggree that the use of DTOs is applicable in most remoting scenarios. However, I still (currently ) believe that in our particular proposed architecture, the actual Domain Objects are more useful and can be transferred using our particular remoting choice (HTTPInvoker).
                Originally posted by Alarmnummer
                Why are they more usefull? And exposing domain objects directly can lead to serious problems like security or ignoring class invariants.
                For example, my Domain Model (Aggregate?) is Customer has -> Addresses. If this exists on the client tier having been returned / created using an Injected [remote] service, I can simply traverse to the addresses. I certainly see that this could also be achieved by creating objects based on DTOs, but I don't like the (code) cost of developing them. Also, when thinking of providing future Web Service layer, this will be driven by the contract required, and therefore I can not see any re-use of these DTOs or the application services that provide them.
                I think I'm trying to mitigate against having a Smart UI anti-pattern, where all business logic is implemented through Application Services, and the domain model has little value.

                Marc

                Comment


                • #9
                  Originally posted by manifoldronin
                  I fail to see how domain objects would couple the client to the server any more tightly than DTO's would. After all, most DTO's are basically "behaviorless" replica of corresponding DO's, aren't they?

                  Of course the client would couple more tightly to the Domain Model, but that should be a good thing IMHO.
                  We use DTO's (but not Spring ) and we recently changed a bunch of our domain objects. We didn't have to change one thing in the DTO's interfaces to our remote clients. This was very good since we have 10+ different clients (remote systems) that we don't control.

                  Cheers

                  Comment


                  • #10
                    Originally posted by baronludwig
                    For example, my Domain Model (Aggregate?) is Customer has -> Addresses. If this exists on the client tier having been returned / created using an Injected [remote] service, I can simply traverse to the addresses. I certainly see that this could also be achieved by creating objects based on DTOs, but I don't like the (code) cost of developing them.
                    I agree that creating DTO's isn't the most fun thing to do, but they are very valuable. And in some cases you can get away with returning domain objects (for example in the presentation layer) but for remoting purposed, I would use DTO's (but that is my personal opinion).

                    Also, when thinking of providing future Web Service layer, this will be driven by the contract required, and therefore I can not see any re-use of these DTOs or the application services that provide them.
                    The DTO's are part of that contract. And especially with webservices, you don't want a tight coupling between client and server. Domain objects are 'just' and implementation detail of your service. You don't want anybody to know about it,

                    Comment


                    • #11
                      I agree fully with second comment, and appreciate the opinion in first.
                      May raise this in a seperate thread, but in other blog posting discussing Spring 2.0 and using AspectJ to dependency inject domain objects, a comment was made as follows.

                      http://www.theserverside.com/news/th...hread_id=38047

                      Looking at this the wrong way
                      Posted by: Rob Harrop on December 13, 2005 in response to Message #193682
                      From my point of view, this code demo is being looked at in the wrong light. Craig isn't trying to lay out a set of best practices, he is simply doing a good job of demoing a new feature in Spring in an easy to understand fashion.

                      As Rod mentioned when we announced this feature, there is still some work to be done in defining the appropriate scenarios for this as opposed to standard service objects.

                      Be assured that we are putting a *lot* of effort into this and we will be laying out a complete set of guidelines as to how we see this working. During this process we will obviously work closely with other people in this space and also with the community as a whole.

                      Regards,

                      Rob
                      As I am considering using the feature to relate a Domain Object to it's service (possibly DDD definition or Spring definition!!), wondered whether the mentioned complete set of guidelines is now available.

                      Marc

                      Comment


                      • #12
                        Use of Java serialization and effects of tight coupling between client and server

                        One piece of advice on avoiding tight coupling between client and server: don't use Java serialization.

                        HttpInvoker uses Java serialization which allows you to use objects returned by the server on the client and vice versa. This can be confusing especially if specific methods on objects returned by the server should not be called on the client.

                        Wanting to avoid changes made to the domain model on the server affecting the client can be another reason to want a loose coupling.

                        One solution proposed is to let the server return DTOs. This may provide a false feeling of decoupling since this domain model will still be tightly coupled to a Rich Domain Model in any but trivial applications.

                        A much better way to decouple the client from the server is to use web services. Granted, Java serialization is faster and simpler to set up but the goal of an architecture is to increase efficiency, fight confusion and increase ease-of-use.

                        Passing DTOs to the client through Java serialization is:

                        - not efficient: since DTOs have to be used on both client and server it's unclear which side ows the DTO, unavoidably leading to design problems.

                        - confusing: which data is expected by the client? What's the contract of the data exchange for individual calls, e.g. to which level should be object graph be populated? This cannot be defined with a DTO domain model, adding to the confusion.

                        - no easy-to-use: although using a DTO domain model in combination with Spring remote access is fast and simple to set up it's not easy-to-use because the client cannot be restricted in the way it uses the DTO domain model. The reason for this is the sharing of one DTO domain model between different method calls leading to a generic domain model that cannot enforce restriction per use case.

                        Web services are also easy to implement and there's a lot of merit in using a contract-first approach. They provide a straightforward answer to decoupling clients and servers, not in the least because you will have to think about the XML schema to use per use case.

                        Comment


                        • #13
                          Originally posted by Alarmnummer
                          If you don't use DTO's, every change in the DO, will be visible in the client -> tight coupling. If you use DTO's, not all changes have to lead to a change in the client. What if you rename a field? Add a field? Rename the class? This doesn't have to lead to a change in the DTO and in turn won't lead to a change in the client -> loose coupling.

                          Why is this a good thing? If I expose my domain objects directly by a webservice for example, and I decide to rename a field, all clients need to be changed. Why is this a good thing?
                          But is it really loose coupling, or is it actually "semantics lost in translation" which will eventually come back and get you? First, implementation changes in DO do not necessarily have to be visible to the client - let's get those out of the way first. Now, yes, any contractual changes would have to be visible to the client, but that's part of the price we have to pay. If you rename something, chances are the semantics of that something has changed, it's actually all the better that the client is impacted and is forced to adjust.

                          Remember, we are not just talking about one change. We are talking about changes accumulated over time, over many releases, and over many come-and-go developers. On almost all the projects I have ever worked on that used DTOs and did not change the DTO's to keep up with the DO changes, after a few releases, the DTO's all invariably became totally different from the DO's, and the mapping and relating between them became extremely hard. You can say that could have been helped with better documentation, I agree, nevertheless the fact that this approach requires better and timely documentation indicates the additional maintenance burden, which the whole idea of loose coupling is supposed to reduce, wouldn't you agree?

                          I guess in the end what I'm trying to say is, tight coupling isn't automatically bad, and loose coupling isn't automatically good. IMHO, coupling itself is actually an indispensable aspect of any sound software engineering, because it kind of forces every piece in a system to relate properly within the system. Sometimes (as is the case here IMHO) some overly loose coupling gives the "decoupled" pieces not more flexibility, but more latitude to err.

                          Comment


                          • #14
                            Originally posted by Alarmnummer
                            The DTO's are part of that contract. And especially with webservices, you don't want a tight coupling between client and server.
                            I think perhaps we want to exclude web services from this discussion, because this whole debate would be moot for web services to begin with - IMHO, there ought not be DTO's at all in a truly interoperable web service interface. Everything is defined in WSDL.

                            Originally posted by Alarmnummer
                            Domain objects are 'just' and implementation detail of your service. You don't want anybody to know about it,
                            Now I realize that this is where our difference comes from - I always consider the domain model part of the visible portion of any system. I mean how can it not be? without a proper domain model, how can a system present to its clients the relationships between the domain objects? or the business behavior provided the domain objects?

                            Comment


                            • #15
                              Originally posted by manifoldronin
                              Now I realize that this is where our difference comes from - I always consider the domain model part of the visible portion of any system. I mean how can it not be? without a proper domain model, how can a system present to its clients the relationships between the domain objects? or the business behavior provided the domain objects?
                              Can't agree more! The domain model is never an implementation only artifact which should be hidden from the presentation tier. As usual the domain model also should be contract based, which presents the relationships between the domain objects to its clients - here the presentation layer. Any change in contract is bound to change the client. While any change in implementation should not have any impact on the client. With such controlled contract based protocol, we can do away with the DTOs, which are, after all, an extra layer - and as someone said, layers are only for wedding cakes . DTOs are pure glue codes which need to be developed and managed - the lesser they are the better for the application.

                              The other issue is regarding the serializability aspect when we consider that the UI layer and the domain layer may not be colocated. Domain objects may be heavy and serialization of entire object graphs may be expensive. Only for such cases, the TO layer may be considered selectively.

                              I think instead of totally banning the DTOs, we need to be flexible in design and apply layering with DTOs only as performance optimization measures.

                              Thanks.

                              Comment

                              Working...
                              X