It really depends on the complexity of your application. Mixing domain objects into the view layer has two possible implications: You’ll be tempted to modify your domain object to accommodate things you need in the view layer Your View layer will contain extra complexity caused by a mismatch between what your domain objects offer and … Read more
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 … Read more
Data Transfer Object classes should follow the name convention defined in the Java Language Specification: Names of class types should be descriptive nouns or noun phrases, not overly long, in mixed case with the first letter of each word capitalized. ClassLoader SecurityManager Thread Dictionary BufferedInputStream […] Suffixing a class name with DTO or Dto won’t … Read more
Quite simply, the reason is one of implementation and drift. Yes, your presentation layer needs to know about your business objects to be able to represent them properly. Yes, initially it looks like there is a lot of overlap between the implementation of the two types of objects. The problem is, as time goes on, … Read more
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.
A Data Transfer Object is an object that is used to encapsulate data, and send it from one subsystem of an application to another. DTOs are most commonly used by the Services layer in an N-Tier application to transfer data between itself and the UI layer. The main benefit here is that it reduces the … Read more