Remoting and Anemic Anti Pattern

[jhh09]

Well, if a domain class has 50 attributes, and there are use cases that consistently concern only a certain subset of them, the first thing I would look at is, why, the class itself. Chances are, even from the domain modeling perspective, it should be broken down to some finer pieces.

I think you are arguing using academic principles, which don't always work so well in real world applications

Take a typical use case - returning search results which can then be used to drill down to view details. My service layer provides two methods for handling this: one to take search criteria and return summary info about the records, another that takes the id of a specific record and returns all the info about that record.

Let's say the records have 20 attributes, only 3 of which are necessary to summarize the record, and you don't want to use DTOs. You could return the full data set for each record, but in a distributed architecture with high traffic that won't scale very well. You could use the domain objects and only populate certain fields, but that just seems wrong. You could use a generic container to hold the data such as arrays of strings or hashmaps, but as you said you lose the benefits of explicit datatypes. You could send the data back as XML with a schema, but someone will still need to dump that data into an object.

And what about the use cases where your search results need to display data from two different objects? Would you design your domain objects to meet that requirement, even if logically the attributes should be in two different classes? This is why like it or not the layer the UI interacts with does need to take the UI into account.

I generally start my designs with the academic "right way" to do things, then I bend my principles as necessary to get the best end result in terms of maintenance, performance, etc. I don't like DTOs because of the extra work involved in copying data between them and domain objects, but there are times (such as returning search results) when I think it is the right approach.

jh

[debasishg]

I generally start my designs with the academic "right way" to do things, then I bend my principles as necessary to get the best end result in terms of maintenance, performance, etc. I don't like DTOs because of the extra work involved in copying data between them and domain objects, but there are times (such as returning search results) when I think it is the right approach.

+1 on this approach. In order to *bend* the principles, one thing that needs to be taken care of is to prevent the implementation of the domain model from being exposed. Just as some one posted before, that of the 50 attributes, we need to break into smaller abstractions since this subset was getting used repeatedly, here we have a potential pitfall of the implementation being leaked out . This smaller abstraction also needs to be a valid artifact of the ubiquitous language for the domain. Otherwise we are out with behaviorless data objects (aka DTOs) hanging around. I am not against DTOs, but we have to have solid justification and use cases to create them.

Cheers.
- Debasish

[dvoytenko]

Let's say the records have 20 attributes, only 3 of which are necessary to summarize the record, and you don't want to use DTOs. You could return the full data set for each record, but in a distributed architecture with high traffic that won't scale very well. You could use the domain objects and only populate certain fields, but that just seems wrong.

I believe the use cases described above are resolved pretty well in JDO and Hibernate (and I assume JPA) using fetch groups, lazy loading, batched lazy loading, etc. Although, I agree that DTO-s can still be necessary even if domain model is used everywhere else in the application. As an example in case of search (full text search) one might need to return an additional field with the text marked up with "matched" words.

[manifoldronin]

I think you are arguing using academic principles, which don't always work so well in real world applications

Well, building software is engineering, not science. And in engineering, there are usually very good and practical reasons for people to come up with these "academic principles". While they don't look as rigid as some other principles (such as "respect the gravity or you fall to death" ), they actually are. The only difference is probably that it may not be the one deciding to sidestep these principles who will be suffering the consequences, but rather some poor dude who has to inherit your architecture/design/code will. Trust me, I learned that the hard way.

Take a typical use case - returning search results which can then be used to drill down to view details. My service layer provides two methods for handling this: one to take search criteria and return summary info about the records, another that takes the id of a specific record and returns all the info about that record.

This is precisely the scenario I said it would lead to in my previous post. Again I'm not saying that it's something absolutely shouldn't be done. But I would need to see a lot of performance gain in order to justify the price of a fragile service API.

Let's say the records have 20 attributes, only 3 of which are necessary to summarize the record, and you don't want to use DTOs. You could return the full data set for each record, but in a distributed architecture with high traffic that won't scale very well.

The question I would ask is, then, "why a distributed architecture?" Or more accurately, why an architecture that has a distribute boundary between the web tier and the service tier? As Rod Johnson quite successfully argued in "J2EE without EJB" (Chapter 15, Performance and Scalability), Object Distribution "achieves scalability by making such a severe sacrifice of performance that much of the scalability serves merely to address inefficiency."

And taking it back to the point in discussion, when the architecture is inherently inefficient, trying to solve that inefficiency by sidestepping OO principles doesn't seem to be a solution at the right level, does it?

You could use the domain objects and only populate certain fields, but that just seems wrong. You could use a generic container to hold the data such as arrays of strings or hashmaps, but as you said you lose the benefits of explicit datatypes. You could send the data back as XML with a schema, but someone will still need to dump that data into an object.

And what about the use cases where your search results need to display data from two different objects? Would you design your domain objects to meet that requirement, even if logically the attributes should be in two different classes? This is why like it or not the layer the UI interacts with does need to take the UI into account.

OK, in that case, someone needs to put together the presentation data from the two different domain objects. That "someone" definitely should not be any of the domain objects for the reason you pointed out. In my design, it would be very natural for the presentation layer to retrieve the domain objects, and extract things it needs. The service layer only needs to expose API to retrieve those domain objects, but does not need to be concerned with anything else.

On the other hand, in a DTO-based design, now the service layer has to be concerned with extracting necessary(mind you, "necessary" for presentation) data and properly assemble the DTO.

So, unless I am missing something, it appears that in order to achieve the goal of "the layer the UI interacts with does need to take the UI into account"(which I completely agree), we ought to avoid DTOs.

[Tristan107]

> So, unless I am missing something, it appears that in order to achieve the
> goal of "the layer the UI interacts with does need to take the UI into account"
> (which I completely agree), we ought to avoid DTOs.

Hi,

I think you are missing somethink :

"the layer the UI interacts with does need to take the UI into account" means the service layer will not manipulate buttons, textfields, page, session and other presentation objects, but you still need a contract between the UI and the service layer for them to work together.

The best way to design this contract is to use DTOs (or at least DTO interfaces).

[rbecket]

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.


I love photography, I own a Photobooth Rental Camarillo, ca. I render service Chocolate Fountain Rental Simi Valley for any occasions.