Transfer objects?

[dominic]

I have a design question: I need objects which contain data that is transfered between the service and the presentation layer. These objects do not belong to the domain model and are not persisted by the DAOs. They are just simple data containers.

How to call these objects and where to put them in the package structure? My first thought was "Transfer objects", but I am not sure if this is really appropriated...

Any suggestions?

[katentim]

They are just simple data containers

Generally you'll try to avoid these unless there's no alternative.

The packaging should reflect where they're used - if you can do this in the web-tier (and web related packages) this would be cleaner for your application.

[dominic]

Thx for your answer. Why should this be avoided?

I need to do calculations based on data from the domain model. My idea was to perform this calculations in the service layer. The service layer would first access the model data via the DAOs, then do the calculations and finally give back the results in the data containers I mentioned.

Of course the calculations could also be done in the presentation layer (i.e. the Controller classes), but I think this is not clean neither...

[Alarmnummer]

Thx for your answer. Why should this be avoided?

I need to do calculations based on data from the domain model. My idea was to perform this calculations in the service layer. The service layer would first access the model data via the DAOs, then do the calculations and finally give back the results in the data containers I mentioned.

I think these object are part of the business layer: because they are the result of a calculation in the business layer.

So I would place them in the business layer. The name? Maybe something that ends with Result or Calculation. If you document these objects good it shouldn't be a big issue imho (it is not something ugly).

[wexwarez]

I use transfer objects myself in a client/server app for the presentation layer. This works great performance wise. My structure is like so:

Domain Objects
DAO
Service Layer <>Business Layer
Transfer Objects
View Layer

My transfer objects are pretty much just java beans. I agree with the other replies that there should be no logic in these transfer objects. Getters and setters should be all you need, occassionally you might have a convenience method that does some formatting or combines a bunch of the fields or something mundane but no real business logic should be there. Stick your logic in your domain objects or in a business layer.

[katentim]

Why should this be avoided?

...if we don’t want a distributed architecture, they’re (DTOs are) redundant and harmful, creating an unwelcome impedance mismatch between business services and callers.
...
Don’t tolerate fake objects unless there’s no alternative.

DTOs can pollute you services API, which should deal with domain objects which can be used by all clients.

[Alan Stewart]

DTOs can pollute you services API, which should deal with domain objects which can be used by all clients.

I'm doing a Spring course run by Ben Alex (project lead for Acegi Security) this week and am reading Domain-Driven Design by Eric Evans.
I'm pretty convinced that DTOs in the context of what I am reading now is a good thing. Ben is teaching us that we should be creating applications with rich-domain objects (not anemic ones) where business logic is solely contained in the domain objects, which are not exposed to the web tier at all. Also, transaction demarcation occurs at the Facade, or Service layer, which allows for transparent persistence.

The way I have been doing projects recently involves, typically, the web controller calling a service method to return a domain object. At this point the transaction has ended. I make changes to the domain object and then call another service method passing in the domain object, such as an update method to persist the data again in another transaction.

With domain-driven design architecture, the domain objects themselves should be responsible for maintaining their own integrity and should not be aware of the persistence mechanism nor the the service or facade layer they're behind. Also, if a facade method retrieves a domain object from the database using Hibernate, for example, and if the service method is wrapped in a transaction, then any changes made in the domain object are persisted automatically when the tranaction has ended - ie working with live objects versus detached objects like the way I used to do it

My packages were basically infrastructure driven. I had a DAO package, a services package and a business or domain package, and then subpackages under each for each business object or concern.
My code will now be structured in vertical slices, which model business problems. For example, I have am employee package, which contains:

• an Employee domain object (DO) containing all the business logic for an employee
• EmployeeDto, which is exposed to clients, mainly web controllers in my case. The Dto basically reflects the domain object but has purely getters and setters of the attributes of the domain object they represent. (use Dozer to do the mapping between Dto and DO - dozer.sourceforge.net)
• EmployeeFacade - service interface containing methods that the web controller can call (find, create, update, delete etc)
• EmployeeFacadeImpl - implementation - ultrathin, no business logic at all
• EmployeeRepository - a DAO interface which has methods like makePersistent (we're still dealing with objects here, not database tables) and makeTransient (which translates to deleting from database - we can't delete an object!)
• EmployeeRepositoryImpl - a Hibernate implementation
• .hbm.xml - Hibernate mapping files
• any business exceptions (runtime) that need to be thrown for the web tier to catch if necessary

Code structured in this way can make use of java's package protected security as well. To model a new business domain problem, I can simply copy the vertical slice package and change the code quite easily.

I'm new to this, so please forgive me if I've mixed my jargon up, but this architecture combined with Spring is a breeze and a pleasure to implement

Alan

[robrudin]

Alan - to me, what you're really talking about is how you implement your Employee service interface, which you call your EmployeeFacade. Am I right in guessing that clients (e.g. a web controller) deal strictly with the EmployeeFacade, and they use the EmployeeDto as an object for receiving and sending data? If so, then your service design is really the same as what I think a lot of folks do, and that's they have an Employee domain object and an EmployeeManager or EmployeeService, where the latter defines all of the operations useful to clients. Business logic would reside in the latter's implementation, and domain logic would reside in the Employee domain object, but there may not be any real domain logic.

I consider domain logic to include both the definition and behavior of the domain, where neither is likely to change, and where the definition is often the hardest part to define, and thus quite valuable. You could probably reuse that definition across multiple applications, so it's hardly an "anemic" class.

A domain object that would have a lot of behavior would be a Coordinate class, as it would include useful operations such as returning radians/degrees, returning the distance to another coordinate, returning a vector representation of itself, etc. Across applications and business, those operations will never change - they're native to the domain.

So anyways - I think what you describe sounds fine, but I see it more as a different implementation approach for implementing your Employee service interface. Ultimately, all your callers care about is what's in the EmployeeFacade interface, and that's the design that really matters.

[Alan Stewart]

Alan - to me, what you're really talking about is how you implement your Employee service interface, which you call your EmployeeFacade. Am I right in guessing that clients (e.g. a web controller) deal strictly with the EmployeeFacade, and they use the EmployeeDto as an object for receiving and sending data? If so, then your service design is really the same as what I think a lot of folks do, and that's they have an Employee domain object and an EmployeeManager or EmployeeService, where the latter defines all of the operations useful to clients. Business logic would reside in the latter's implementation, and domain logic would reside in the Employee domain object, but there may not be any real domain logic.

Yes, clients just deal with the facade - the same as I used to do it, but with the difference that the service or facade implementations do not do any adjustments to the domain objects at all. The DOs do not know about the facade either . Also, using the vertical slice approach prevents any client from accessing the DOs directly if the setters and constructors of the DO are package protected. Moreover, changes in the state of the DO are handled in the one (transaction-wrapped) call to the facade., rather than for example, a 2 step process now where I get the DO in one transaction and then update it in another.
Cheers
Alan

[erimag]

Very nice architecture, Alan. I'm also reading Domain Driven Design, and your approach is along the lines of what I was considering for my project as well.

One concern I have, however, is the package protection limiting the interaction between different rich domain objects. The natural solution to this is of course to put all domain objects that need to call each others' methods directly in the same package (as in DDD figure 7.8). This could, however, result in very large, and at least in my mind, cluttered packages if you have to include all the infrastructure classes as in your employee example. Is this just something that I need to "get over" or are there any neat solutions that you have thought of?

One idea I have is to make all methods on domain objects public and use AOP to limit direct access to them from the web tier, instead of using package scoping. That way all the infrastructure classes could go in subpackages that aren't prevented from calling the domain methods (employee.persistance, employee.exception etc.), and the main packages become less cluttered...

This might do away with the need for DTOs in the web tier as well, since you should be able to use the real domain objects (but limited by AOP to only getter/setter methods). That might mess up transaction demarcation and stuff done by the Facade though, not sure.

I'm just learning this as well.... any thoughts?

/Erik