data-transfer-objects

One mentor I respect suggests that a simple bean is a waste of time - that value objects 'MUST' contain some business logic to be useful. Another says such code is difficult to maintain and that all business logic must be externalized. I realize this question is subjective. Asking anyway - want to know answers from more perspectives. Panagiotis Korros You should better call them Transfer Objects or Data transfer objects (DTO) . Earlier this same j2ee pattern was called 'Value object' but they changed the name because it was confused with this http://dddcommunity.org/discussion

In which scenario can I use those design patterns in n-tier architecture? DTO is the object that you can use at the boundaries of the system. When you have a SOAP web service for example and you want to return response you would use DTO. It easier to deal with than actual XML that has to be returned over the wire. DTOs are often generated by tools, based on WSDL for example. DTO are often tailored to the needs of service consumer and can be affected by performance requirements. Value objects on the other hand live in the core of the system. It captures pieces of business logic and maybe

Could you please explain the difference between Transfer objects and Domain objects in simple terms ? And if u could give a Java example, that would be great.. DTOs don't have any logic. They only have fields (state). They are used when transferring data from one layer/subsystem to another Domain objects can have logic (depending on whether you are using domain-driven design or have anemic data model) and they are usually related to the database structure. If using anemic data model (i.e. your domain objects don't have any logic), DTO and domain object can be the same object. Related: http:/

Given this scenario where you have "transfer objects" (POJO's with just getters/setters) which are passed by a client library to your API, what is the best way to name the transfer objects? package com.x.core; public class Car { private String make; private String model; public Car(com.x.clientapi.Car car) { this.make = car.getMake(); this.model = car.getModel(); } } In this example your main class and your transfer object both have the name Car . They are in different packages but I think it's confusing to have the same name. Is there a best practice on how to name the transfer objects? I

One part of domain-driven design that there doesn't seem to be a lot of detail on, is how and why you should isolate your domain model from your interface. I'm trying to convince my colleagues that this is a good practice, but I don't seem to be making much headway... They use domain entities where ever they please in the presentation and interface layers. When I argue to them that they should be using display models or DTOs to insulate the Domain layer from the interface layer, they counter that they don't see the business value in doing something like that, because now you have a UI object

I've recently overheard people saying that data transfer objects (DTOs) are an anti-pattern . Why? What are the alternatives? KLE Some projects have all data twice . Once as domain objects, and once as data transfer objects. This duplication has a huge cost , so the architecture needs to get a huge benefit from this separation to be worth it. Gabe Moothart DTOs are not an anti-pattern. When you're sending some data across the wire (say, to an web page in an Ajax call), you want to be sure that you conserve bandwidth by only sending data that the destination will use. Also, often it is