Question

Background:

I have a design pattern problem that I was hoping someone may be able to solve. I program in PHP but I believe DAO/VO is popular in Java.

I have been using MVC for many years now. I designed a shopping that was MVC but used procedural programming. Thus recently I decided to develop the cart again, using OO.

Problem:

The problem I was faced with was that my Product class did not make sense to have a RetrieveAll() method.
E.g. If I had 10 products listed, from which instance would I call the RetrieveAll() method? I would have 10 choices.

Solution:

Thus, I found the DAO/VO pattern.
Unless I have not researched this pattern enough – I believe that each DB table must have a Model + DAO. No model or DAO should know about another set of models or DAO’s. Thus being encapsulated.
The pattern makes perfect sense, pulling the database layer away from the Model.

However. In the shopping cart, my products are assigned categories.
A category could be electronics, clothing, etc.

There are 3 tables:
– Category (pid, name)
– Category Item (iid, name)
– Category Link (pid, iid)

From an MVC approach, it doesn’t make sense of which DAO the controller should be talking to?

Should it be:

• The controller talks to all 3 DAO’s and then return the appropriate data structure to the View?
• Or should the DAO’s talk to one-another (somehow) and return a single structure back to the Controller?

Please see here for example (image)

Answer 1

I’m not sure what do you mean by VO. Is it value object?

I’m a huge fan of the DDD (domain driven design) approach (though I don’t consider my self as guru in it). In DDD you have so called Services. Service Is an action that operates on your domain and returns data. Service encapsulates the manipulation with you Domain data.

Instead of having the controller to do all the domain logic like what items to retrieve, what DAO’s to use and etc (why controller should care about the Domain anyway?), it should be encapsulated inside the Domain it self, in DDD case inside a Service.

So for example you want to retrieve all the Category items of the category “electronics”.
You could write a controller that looks like this (forgive me if the code have invalid syntax, its for the sake of example):

public function showItemsByCategoryAction($categoryName) {
  $categoryId = $categoryDAO->findByName($categoryName);
  if(is_null($categoryId)) {
    //@TODO error
  }

  $itemIds = $categoryLinkDAO->getItemsByCategoryId($categoryId);
  if(empty($itemIds)) {
    //@TODO show error to the user
  }

  $items = $categoryItemDAO->findManyItems($itemIds);

  //@TODO parse, assign to view etc
}

This introduces at least two problems:

1. The controller is FSUC (Fat stupid ugly controller)
2. The code is not reusable. If you would like to add another presentation layer (like API for developers, mobile version of the website or etc), you would have to copy-paste the same code (expect the part of the view rendering), and eventually you will come to something that will encapsulate this code, and this is what Services are for.

With the Services layer the same controller could look like

public function showItemsByCategoryAction($categoryName) {
  $service = new Item_CategoryName_Finder_Service();
  $items = $service->find($categoryName);

  if(empty($items)){
    //@TODO show empty page result, redirect or whatever
  }

  $this->getView()->bind('items', $items);
}

The controller is now clean, small, and all the Domain logic is encapsulated inside a service that can be reused anywhere in the code.

Now some people believe that the controller should know nothing about DAOs and communicate with the Domain only by using Services, other says that its ok to make calls to DAOs from the controller, there are no strict rules, decide what suits better for you.

I hope this helps you!
Good luck 🙂