Tester-Doer pattern Or TryParse?

samvan · November 11th, 2010, 01:29 PM

I have finished studying the code up to the client proxy section on chapter 6. I have a few questions regarding the

CanReserveTicket

method of the TicketService class.

Why does Event.ReserveTicket need to throw an exception when it cannot complete? Why not just return null and let TicketService.ReserveTicket test for Null?

Like

Code:

 
public TicketReservation ReserveTicket(int tktQty)
{
if (!CanReserveTicket(tktQty))
    return null;
    //ThrowExceptionWithDetailsOnWhyTicketsCannotBeReserved();
 
    TicketReservation reservation = TicketReservationFactory.CreateReservation(this, tktQty);
 
    ReservedTickets.Add(reservation); 
    return reservation;
}

If throwing an exception is necessary, why do we not just assume Event.ReserveTicket will not fail since there is a surrounding try catch block on the TicketService.ReserveTicket method? Since we are already testing it in Event.ReserveTicket, why do we need to test again using the tester-doer pattern?

Like

Code:

 
try
{
    Event Event = _eventRepository.FindBy(newGuid(reserveTicketRequest.EventId));
    TicketReservation reservation;
    reservation = Event.ReserveTicket(reserveTicketRequest.TicketQuantity);
    _eventRepository.Save(Event);
    response = reservation.ConvertToReserveTicketResponse();
    response.Success = true;
}
catch (Exception ex)
{
    // Shield Exceptions
    response.Message = ErrorLog.GenerateErrorRefMessageAndLog(ex);
    response.Success = false;
}

Or maybe a TryParse pattern would be a better choice (similar to my first question about testing for null)?

Like

Code:

reservation = Event.TryReserveTicket(reserveTicketRequest.TicketQuantity);
 
if (reservation == null) {
    response = String.Format("There are {0} ticket(s) available", Event.AvailableAllocation());
    response.Success = false;
}
else {
    _eventRepository.Save(Event);
    response = reservation.ConvertToReserveTicketResponse();
    response.Success = true;
}

elbandit · November 12th, 2010, 04:59 AM

Samvan,

The exception handling is designed to handle any exceptions thrown and log them.I didn't set up and WCF exception fault contracts intead I handled all exceptions and just returned a success flag to show if the call worked or not.

Quote:

if (Event.CanReserveTicket(reserveTicketRequest.Ticke tQuantity)) // Tester
{
reservation =
Event.ReserveTicket(reserveTicketRequest.TicketQua ntity); // Doer
_eventRepository.Save(Event);
response = reservation.ConvertToReserveTicketResponse();
response.Success = true;
}
else
{
response.Success = false;
response.Message = String.Format(
âThere are {0} ticket(s) available.â,
Event.AvailableAllocation());
}

The exception in the ReserveTicket method is for cases when the client by passes the check on whether he can reserve a ticket. I guess its just personal preference or whatever you feel is more clear for the client using it. Thinking about it there might be another way to communicate an issue when reserving a ticket that didn't make use of exceptions to exporess a failure. Maybe have the ReserveTicket method return a response with the number of tickets reserved?

Cheers
Scott

samvan · November 12th, 2010, 07:29 AM

Thanks Scott for your reply.

I think what I am really asking is this:

Since the doer method (Event.ReserveTicket) actually has a tester built in (to throw exception in case the client bypass the tester in the service layer), we are effectively testing "twice" if the client uses the tester-doer pattern in the service layer (as in our case).

In the example in the book it may not be a problem, but if the tester needs to access something outside the machine it may not be ideal.

Maybe a flag to store whether CanReserveTicket has been called, and check the flag in the Event.ReserveTicket method?

elbandit · November 12th, 2010, 08:52 AM

Yes good point. In this senario there is no overhead for checking twice but in other systems there may well be. Yeah makes sense to include a flag to store whether CanReserveTicket has been called, and check the flag in the Event.ReserveTicket method as long as nothing else can affect the outcome in between.