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.

p2auljr (2) [Avatar] Offline
#1
After going over the facade and service layers in the domain model, I'm a little confused on whether they are using procedural code rather than object oriented programming. Most of the facade and service layer classes do not hold any state and are not performing any behavior on their own data. So aren't they implementing the transaction script pattern? Would it be acceptable for the PendingServiceFacade and/or PendingService to have a PendingOrder as its data that it then acts upon?
simbo1905 (30) [Avatar] Offline
#2
Re: Are service and facade classes implementing transaction script pattern?
A very wise question. I struggled with this one a while. If we read chapter six of the book Clean Code by Robert C. Martin it says that it is a good thing to use either exposed getter/setters in a "procedural style" or pure encapsulation which does not expose any internal fields in a "OO style". Here is a link to a post which discusses this matter. This post discusses that and suggests that an large record orientated system an entity that models a data structure with lots of getters/setters is the natural fit.

http://www.manning-sandbox.com/thread.jspa?messageID=91995#91995

Clean Code also says that objects should do one thing and do it well - persisting itself or knowing how to do "muti-entity" Service operations violates that rule. Consider that JPA itself is a POJO technology standard and its EntityManager is stateless: does that make it a procedural thing?

I feel that if your writing a record orientated database CRUD system then fundermentally your modelling a "data structures + operations" system. If that makes your domain model look like data structures + operations then your doing good OO domain modelling. To get the best out OO you should look to have good encapsulation (including not making all setters public), a clear division of responsibilities, polymorphism and the like. At that point would should we still call it a procedural coding style or an OO implimentation of a records and processes orientated system?