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.

orionlee (1) [Avatar] Offline
#1
Hi,

I have a question concerning about the plumbing / mapping code needed in conjunction with the service pattern.

Let's take a variant of the PlaceOrderService you use in your book (For the discussion here, service or servicefacade is pretty much equivalent here).

PlaceOrderServiceResult updateDeliveryInfo(String pendingOrderId,
Address deliveryAddress,
Collection<MenuItem> menuItems,
Date deliveryTime);

In the context of a typical webapp, the service/servicefacade will be invoked by the controller. In most MVC frameworks tend to have some data binding mechanism to convert a web form submission to one object and perform some validation.

So to implement the update operation, one will then
1. create a Webtier bean, e.g., DeliveryInfoFormBean (StructActionForm, Spring MVC / JSF pojos) that holds all the information, and possibly doing some validation.
2. in the controller implementation, convert the Webtier bean into the list of parameters taken by the service / servicefacade
3. In the service implementation, take the list of the parameters, and update the actual domain objects.

It's quite tedious to do all the plumbing here:
1. define the webtier form bean that, in many cases, identical (or near identical) to the actual domain objects in terms of properties (not the methods)
2. conversion from the webtier form bean to a list of parameters in the service method.
3. conversion from the list of parameters in the service method to the actual domain object property.

To get things done in time, one will be tempted to find ways to reduce the plumbing code, possibly with cutting corners. For example, one might be tempted to bypass the service layer, and access repository layer to cut out step 2 (webtier form bean to a list of parameters in the service method). Certainly, it might introduce its own issues in exposing too much details to business layer.

Do you have any suggestion reduce the plumbing code in such cases?

Thanks.

- sam
Karthik (1) [Avatar] Offline
#2
Re: service/facade update method binding with presentation tier
hi chris,

your book is awesome and very practical. a pragamtic developer like me has taken to it like a fish to water.

however i strongly request you to consider including the presentation tier as an in-scope activity for the next rev. of PIA

hi sam,

very good question. i've blogged this issue in

http://jroller.com/page/intriguedbyjava?entry=domain_driven_design_aggregates_and

the bottomline, i've realized is that to use web frameworks to avoid the plumbing code, your pojos will also double up as javabeans to expose public setter methods.

now the presentation layer will directly update your pojos using setters (which typically you can wire in your jsp using some form of ognl).

after that when the facade/service kicks in, instead of calling updateDeliveryInfo, we would end up calling validateDeliveryInfo()

these are just my thoughts, but again, your question is very valid and pertinent.

i would love to know what chris has to say.

thanks, karthik
simbo1905 (30) [Avatar] Offline
#3
Re: service/facade update method binding with presentation tier
Why not use Dozer or beanutils or something to map the form bean onto a DTO and pass that into the façade? Else put the a domain object into the session and map the form beans onto that? Else if your concerned about too much data in the session why not wrap the IDs into some strongly typed Handle class that has a "setFormBean" method and pass that into the Façade to have that call the loadById of the domain object and then load the data and apply the mapping. If you have strongly typed form beans (different class per form bean) you can add a method safe method "mapToEntity( MyEntity e)" to have the façade delegate the mapping logic to the UI bean.

We use the stateful detached entities approach mainly as we have a highly stateful UI framework with an application where the entities are editable records which works well with using the detached and exposed entity approach.