How would you handle this? – Service Layer slowly getting polluted (or so it seems)!

October 21st, 2009 by rvdavid Leave a reply »

Just going through the motions here using Zend Framework and an implementation of Service Layer and Domain Model to form my domain layer.

I must admit – I thought I had made a break through, but alas, more analysis paralysis.

I’m finding that I’m abusing the accessiblity of the Service Layer.

Here’s an example:

  • I’ve got an application which manages users.
  • I have a User Model and have User Service as the pivot point where application logic gets ported to to business logic.

The User Service class provides the following functionality:

  • CRUD (Create, Read, Update and Delete) which pretty much proxies to the Model.
  • Also, the Service layer looks after Authentications
  • and Authorisation.

All pretty straight forward, at this point. Of course you’ll also have:

  • A Form factory in the UserService class as well as
  • a List method which returns an assoc array of mutiple results based on criteria.

However, what would you do in situations where the client has requested for the Ability to update several records via a CSV import.

I thought hey, ok, I’ll:

  • Add a “get Upload Update File” form…
  • Then I’ll add an “Upload Method” to process the upload,
  • I need to delete this file also – now I’ll add a “delete file” method,
  • More thinking brought on I need to centralise file name creation so that ensure that I am only using one name.
  • I’m using a csvreadstore to read the csv file for review – so I need to have a “readstore” method for the csv file.
  • I’ll also need to validate this file
  • FInally, I need to massage the data from the CSV into my domain model and either update one by one by one or update it all as a big group.

But this will leave me with an extremely heavy service layer and a somewhat thin Model object.

I don’t know what to do – I can do it both ways, but it’s just not blatantly clear as to which direction I should be pushing this to.

What would you do as an OOP programmer? Can you crack this little dillema I’m having? Am I heading in the right direction? Should I create a new Service layer called UpdateUsersService (which of course seems like a bad idea to me).

I’m open to feedback – where do you think I should go?

if you enjoyed this post, make sure you subscribe to my RSS feed!
You can also follow me on Twitter here.

No related posts.

Advertisement

3 comments

  1. Tomas says:

    Hi,

    bases on the OOP rule called ‘Single Responsibility Principle’ (http://giorgiosironi.blogspot.com/2009/09/solid-part-1-single-responsibility.html)
    ) I would recommend to create UpdateService service and keep it separate from the UserService, because that import can have various source and could also write to different Entities.

    That UpdateService could have following features:
    *) read from various sources based on provided adapter (csv, xls, SOAP etc) http://giorgiosironi.blogspot.com/2010/01/practical-php-patterns-adapter.html
    *) write to various Entities that can be just injected through some generic setOptions() or reflection (etc…)

    The above would keep the UserService thin and move this additional functionality into another class,
    that can handle this functionality well and is not coupled only to User.

    Some example:

    $fileCsv = $form->getUploadedFileContent();

    $adapter = new CsvAdapter($fileCsv);

    $updateHandler = new UpdateService($adapter);
    $userService = new UserService();

    $updateHandler->updateEntities($userService);

    class UpdateService {

    ///

    public function updateEntities(BusinessService $service) {

    foreach ($this->getAdapter()->getRows() as $row) {
    $entity = $Service->findById($row->getId());

    // This can be done various ways and even can be some checking included.
    $entity->loadFromArray($row->toArray());

    $service->save($entity);
    }

    }
    }

    PS: thanks giorgio for all his blogs :)

Leave a Reply

Notify me of followup comments via e-mail. You can also subscribe without commenting.