The Author Online Book Forums are Moving

The Author Online Book Forums will soon redirect to Manning's liveBook and liveVideo. All book forum content will migrate to liveBook's discussion forum and all video forum content will migrate to liveVideo. Log in to liveBook or liveVideo with your Manning credentials to join the discussion!

Thank you for your engagement in the AoF over the years! We look forward to offering you a more enhanced forum experience.

simbo1905 (30) [Avatar] Offline
#1
Reading POJOs In Action again three years on smilie I see that it is important to note that the Food To Go case study in the book is largely a database CRUD application. With such applications the entities tend to be records within the system. There is lots of browse, add and update and some complex 'buy now' like logic. With such "records oriented" systems the PiA approach works and works very well.

I would make only very minor enhancements to the approach in the book when working with desktop like clients (e.g. ZK RIA AJAX framework or Swing) which is to pass the recorded entities into, as well as out, of the facades (ZK is highly stateful and databinds to your entities such that you can pass the updated entity down to the facades on subsequent AJAX events).

There has been some lively discussion around patterns for using JPA over on these blog posts where POJOs In Action gets a mention in some comments:

http://blog.xebia.com/category/jpa/implementation-patterns/

POJOs In Action says to use the detached entities as DTOs. This seems to conflict with some reports that exposing the fields within your entities is a Bad Thing as it violates the rule that objects should hide their internal structure. There are some recommendations that data be copied into DTOs to exchange with the client.

Something which gets mentioned via comments and links over at that blog is Chapter 6 of the book Clean Code by Robert C. Martin. That chapter says that going with lots of exposed properties is a valid strategy, another being to totally hide the fields and only exchange messages (i.e. method calls ideally via an interface) with a domain object. The Clean Code book states that both are valid but are diametrically opposed approaches. The book warns against using both approaches on the same system.

PiA on first blush seems to violate the recommendations of Clean Code not to mix the strategies about exposing fields. The record entities (Customer, Order, MenuItem) and the like take the data structures approach. The other parts of the domain model, the services and the repositories, take the second strategy. With those domain objects the client fires messages at them over the interfaces without any visibility of what they have internally.

Thinking it through the approach recommended in the PiA is very structured and considered as to which strategy to take about fields on which type of domain object. With the record entities you use the data structures approach and expose the fields with getters for the client. With the services or repositories you take the hidden internal structure approach. I therefore don't think that it violates the Clean Code recommendation which I interpret to mean "don't mix the approaches for the same types of objects" rather than it suggesting that in a record CRUD system you would pick one or other strategy. To do so would necessitate either mapping your record entities onto identical DTOs else providing getters/setters for your services. Neither of which would be at all satisfactory.