1

I'm new to MVCish structure, so go easy on me, please. I'm coding my own small MVCish "framework" for understanding purposes. Bit by bit, I intend to understand how all fits together the right way.

Relying heavily on How should a model be structured in MVC? by tereško and the fact that Domain Object != Domain Object Collection, I'm trying to figure out a way to handle Domain Object creation in bulks and their respective insertion in the Collection.

Oh his example, he passes a single ServiceFactory instance to both the controller and the view. This instance has a MapperFactory and a DomainObjectFactory injected on its constructor. There is no Collection Factory. 

$serviceFactory = new ServiceFactory(
    new DataMapperFactory($dbhProvider),
    new DomainObjectFactory
);

/* 
 * Initialization of View 
 */
$class = '\\Application\\View\\' . $request->getResourceName();
$view = new $class($serviceFactory);
$view->setDefaultTemplateLocation(__DIR__ . '/templates');

/*
 * Initialization of Controller
 */
$class = '\\Application\\Controller\\' . $request->getResourceName();
$controller = new $class($serviceFactory, $view);

ServiceFactory.php would be something like

class ServiceFactory
{
    private $domObjFactory;
    private $mapperFactory;

    private $services = array();

    public function __construct(MapperFactory $mapperFactory, DomObjFactory $domObjFactory)
    {
        $this->mapperFactory = $mapperFactory;
        $this->domObjFactory = $domObjFactory;
    }

    public function create($name)
    {
        if ( array_key_exists($name, $this->services) === false )
        {
            $serviceName = '\Vendor\\'.$name.'Service';

            $this->services[$name] = new $serviceName($this->mapperFactory, $this->domObjFactory);
        }

        return $this->services[$name];
    }
}

As an example, let's say I have a Domain Object called Contract and I want my view to show them all in a list. It should probably tell the "model" something like $ContractService->fetchAll(), which would instantiate a collection and tell the mapper to populate it with all the contracts. Right?

Considering the collection should contain Domain Objects and a method like $ContractMapper->fetchAll($collection) should probably create a bunch of them, how to handle their creation!?

  • Should I have a dedicated Collection Factory also?
  • Should I create single Domain Objects with a method inside the Collection Object?
  • Should I create single Domain Objects with a method inside the Collection Mapper?
  • If so, should I inject the Domain Object Factory inside one of them? (This would probable require a ServiceFactory with a bunch more Factory dependencies being injected, which is bad, right?)

I believe this could be easily achieved in a poorly coded way, but I'm trying to find the most elegant and clean solution.

Community
  • 1
  • 1
pilger
  • 11
  • 2
  • 3
  • @RyanVincent, thanks for the input! About the view having a factory. The view only receives a ServiceFactory instance through injection. Teresko did that in his example in order to ensure both Controller and View interact with the same instance of the Services they need. Anyways, this is irrelevant to my question, since it was about the collection and instantiation of domain objects. – pilger Jul 23 '16 at 18:53
  • @RyanVincent About the collection. It doesn't have methods to look up objects. The mapper does, hence the `$ContractMapper->fetchAll($collection)`. The collection needs to receive (or create) instances of the domain objects that are contained within it. My question is how and where to create the domain objects the collection should contain. – pilger Jul 23 '16 at 18:59
  • @RyanVincent `The view is passed the data it needs to process so has no need to look anything up`. The reliable articles I've read all say that the View should talk **directly** to the Model. In my understanding, the Front Controller should initialize the View object based on the route given (e.g.: "\contracts\edit\12" should initialize the ContractView) and the Controller itself should only be in charge of saying "hey View, I'm done editing the contract with foreign key 12, do your thing now". Right? – pilger Jul 23 '16 at 19:04
  • Welcome to the many interpretations of MVC. :) They are all correct. Just pick one that you are happy with :) – Ryan Vincent Jul 23 '16 at 22:18
  • imo, The purpose of all the different MVC is to decouple processes and provide single places to put actions the code needs to do. I should explain what ideas I am currently using for 'MVC'. Please note, I am not using the code mentioned in the links but I am using the methods. [Action-Domain-Responder: A Tentative MVC Refinement](http://pmjones.io/adr/). Also: [Organizes a single user interface interaction between a web client and a web application into three distinct roles.](https://github.com/pmjones/adr). – Ryan Vincent Jul 24 '16 at 09:04
  • @RyanVincent Awesome info. Many thanks. Web applications do demand a variation on the original MVC paradigm. But has very little to do with the question I asked. At the moment I really wanna focus specifically on how domain objects should be created regarding its collections, considering the use of factories. That's something that belongs to the Model (or Domain) itself and doesn't really affect the Controller or View. – pilger Jul 24 '16 at 17:25
  • you'll benefit from this answer: http://stackoverflow.com/questions/11942842/who-should-handle-the-conditions-in-complex-queries-the-data-mapper-or-the-serv/11943107#11943107 – jeremy Jul 24 '16 at 18:48
  • @Jeremy, thanks! I've actually had read that already and it was, indeed, helpful. But it doesn't explain the use of factories in the same situation. How a Doman Object Factory would work with a Collection!? That's what I'm trying to figure out. – pilger Jul 25 '16 at 16:58

0 Answers0