On 27 March 2014 22:49, Tomoloju, Ola <[email protected]> wrote:

>
> The getBasket () action method does the following:
>
> 1.       Checks if there exists a basket for the a product (BasketItem)
>
> 2.       If there is no basket, it creates one and adds the product
>
> 3.       If there is an existing basket it, it adds the product to the
> basket
>
>
>
> So, I am not sure if your earlier statement apply "RO only supports the
> idea of passing a reference to an existing persistent object" , Sorry if I
> was not clear enough.
>
> The method name might be misleading, but getBasket (adds BasketItem to the
> basket) and returns the basket.
>
>
The existing persistent object would be the BasketItem.

Looking at the sample data, though, I think your domain is a bit confused.

What exactly are the items being added?  It looks like a van rental system.
 Does the customer rent a specific van, or is that they rent the
specification for a van?  In fact, it seems even more involved, that
there's a start and end destination.

It's like the difference between a book and a title: a book is a tangible
thing ("you can stub your toe on t"), whereas a title is an ISBN entry in a
catalog.  A book references its title.  In a library system you would
reserve a title ("Harry Potter"), but borrow a book ("our third copy of
Harry Potter with a torn page").

Going back to your domain, you need to first create the vanRental, then
call getBasket to lazily create the basket and add the vanRental into it.
 You are right that the action is misnamed; I think that putItemIntoBasket
(with IDEMPOTENT semantics) would be a better name.

Why not sketch up a little UML diagram (in yuml.me) to verify all this,
before continuing coding.  One of the major benefits of Isis is that it
really forces you - early on - to clarify your domain.  If you don't have
it right, it's not really possible to ignore it with the other layers of
your app.

Dan

>
>

Reply via email to