We should note that the DTO described above models the search result screen not the business domain. That's an important distinction. The DTO may change completely if the screen changes or be deleted if the screen is deleted. What you really want to do is model the business problem as entities and mature that model carefully and keep DTOs to an absolute minimum. Screens which work closely with a few entities in detail should work with root entities that work control other entities directly.
We should note that the DTO described above models the search result screen not the business domain. That's an important distinction. The DTO may change completely if the screen changes or be deleted if the screen is deleted. What you really want to do is model the business problem as entities and mature that model carefully and keep DTOs to an absolute minimum. Screens which work closely with a few entities in detail should work with root entities that work control other entities directly.
We should note that the DTO described above models the search result screen not the business domain. That's an important distinction. The DTO may change completely if the screen changes or be deleted if the screen is deleted. What you really want to do is model the business problem as entities and mature that model carefully and keep DTOs to an absolute minimum. Screens which work closely with a few entities in detail should work with root entities that control other entities directly.
- 308
- 2
- 11
When you say "send to the client," as it is a webapp, this really means render to the browser (or mobile app) in the servlet tier. In which case, it's typically your own teams code and there is little or no value to copying entities into DTOs. There is overhead to copying into DTOs which is a reason not to do it. The exposed domain model pattern considers copying to DTOs as an anti-pattern. The POJOs In Action book by Chris Richardson is old, but still excellent and covers the exposed domain model pattern. The library versions in the sample code isare now very out of date as it is many years later but the design and implementation approaches described in detail are IMHO timeless.
There is a use for some DTOs when writing code with entities. The canonical use is a search results screen which is, say, a grid with many columns which come from many entities. An example would be a summary of customer orders. That would have each row be taken from entities such as customers, addresses, products, orders etc. In such a case it is wasteful and slow to load all the entities to memory to render them in the flat search results screen. In that case you can create a DTO which represents a row on the screen and use JPA select new syntax as described in this answer to join across entities and pull specific fields off themwhich is translated into the DTO object. JPA maps thea database join query result set directlythat is efficiently loaded into the DTO object.
When you say "send to the client," as it is a webapp, this really means render to the browser (or mobile app) in the servlet tier. In which case, it's typically your own teams code and there is little or no value to copying entities into DTOs. There is overhead to copying into DTOs which is a reason not to do it. The exposed domain model pattern considers copying to DTOs as an anti-pattern. The POJOs In Action book by Chris Richardson is old, but still excellent and covers the exposed domain model pattern. The sample code is very out of date but the design and implementation approaches described in detail are IMHO timeless.
There is a use for some DTOs when writing code with entities. The canonical use is a search results screen which is, say, a grid with many columns which come from many entities. An example would be a summary of customer orders. That would have each row be taken from entities such as customers, addresses, products, orders etc. In such a case it is wasteful and slow to load all the entities to memory to render them in the flat search results screen. In that case you can create a DTO which represents a row on the screen and use JPA select new syntax as described in this answer to join across entities and pull specific fields off them into the DTO object. JPA maps the query result set directly into the DTO.
When you say "send to the client," as it is a webapp, this really means render to the browser (or mobile app) in the servlet tier. In which case, it's typically your own teams code and there is little or no value to copying entities into DTOs. There is overhead to copying into DTOs which is a reason not to do it. The exposed domain model pattern considers copying to DTOs as an anti-pattern. The POJOs In Action book by Chris Richardson is old, but still excellent and covers the exposed domain model pattern. The library versions in the sample code are now very out of date as it is many years later but the design and implementation approaches described in detail are IMHO timeless.
There is a use for some DTOs when writing code with entities. The canonical use is a search results screen which is, say, a grid with many columns which come from many entities. An example would be a summary of customer orders. That would have each row be taken from entities such as customers, addresses, products, orders etc. In such a case it is wasteful and slow to load all the entities to memory to render them in the flat search results screen. In that case you can create a DTO which represents a row on the screen and use JPA select new syntax as described in this answer to join across entities which is translated into a database join query that is efficiently loaded into the DTO object.
There is a use for some DTOs when writing code with entities. The canonical use is a search results screen which is, say, a grid with many columns which come from many entities. An example would be a summary of customer orders. That would have each row be taken from entities such as customers, addresses, products, orders etc. In such a case it is wasteful and slow to load all the entities to memory to render them in the flat search results screen. In that case you can create a DTO which represents a row on the screen and use JPA select new syntax as described in this answer answer to join across entities and pull specific fields off them into the DTO object. JPA maps the query result set directly into the DTO.
There is a use for some DTOs when writing code with entities. The canonical use is a search results screen which is, say, a grid with many columns which come from many entities. An example would be a summary of customer orders. That would have each row be taken from entities such as customers, addresses, products, orders etc. In such a case it is wasteful and slow to load all the entities to memory to render them in the flat search results screen. In that case you can create a DTO which represents a row on the screen and use JPA select new syntax as described in this answer to join across entities and pull specific fields off them into the DTO object. JPA maps the query result set directly into the DTO.
There is a use for some DTOs when writing code with entities. The canonical use is a search results screen which is, say, a grid with many columns which come from many entities. An example would be a summary of customer orders. That would have each row be taken from entities such as customers, addresses, products, orders etc. In such a case it is wasteful and slow to load all the entities to memory to render them in the flat search results screen. In that case you can create a DTO which represents a row on the screen and use JPA select new syntax as described in this answer to join across entities and pull specific fields off them into the DTO object. JPA maps the query result set directly into the DTO.
- 308
- 2
- 11
- 308
- 2
- 11