1

I'm quite new to ORM's and just a bit experienced with MVC, so I was wondering the following:

I have ORM models User, Organization.. When I want to search all users in organization 1 I do the following:

$users = Model_User::query()->where('organisation_id', 1);

Should i just put that straight in the controller, or somewhere else?

tereško
  • 58,060
  • 25
  • 98
  • 150
Sander
  • 1,402
  • 2
  • 21
  • 44
  • Well it depends, is this something your model needs to (be able to) know all the time (Model)? Or is it to display specific information in a specific page (Controller)? Or maybe even as a widget on every page (I'd still go for Controller), HMVC would be of better use for such a widget though. – AmazingDreams Jul 27 '13 at 09:15
  • In this case it's used as output to a page, though since I've been using CodeIgniter for a while, in there I'd make a function in a model which outputs the object-array. – Sander Jul 27 '13 at 09:17
  • I'd go for the Controller. It is not a complex query, so if you ever need it anywhere else what's the loss? – AmazingDreams Jul 27 '13 at 09:21
  • *(related)* http://stackoverflow.com/questions/3109715/understanding-mvc-whats-the-concept-of-fat-on-models-skinny-on-controllers/3109890#3109890 – Gordon Jul 27 '13 at 09:22

2 Answers2

3

Ideally you should have another layer between ORM (or data layer or persistence or repository) and controller. You can call this services/AppServices/BLL.

This layer should handle the extra logic, whereas your ORM should get data directly from database/other sources as mapped, and controller should just call next layer depending on user request.

ORM:

Users GetUsers() //for all users

Service:

Users GetUsersForOrganization(int orgId) //call orm method and filter for organization id
Arghya C
  • 9,805
  • 2
  • 47
  • 66
  • 2
    Unfortunately, those frameworks do not have a model layer. Only a collection of active records, which they like to pretend are "models". – tereško Jul 27 '13 at 09:22
0

When i work with MVC i always have a Value Object Data1 and an mapper Data1Mapper. The ValueObject itself is for holding the data and the mapper contains methods like: find, save, delete, fetchAll etc...

In the controller i instantiate the mapper and access the needed method.

Example:

class DataMapper {
    public function __construct() {
        //fetch TableDateGateway
    }

    public function find() {
        //find by identifier
    }

    public function save($data) {
        //insert or update
    }
}

class Data {
    protected $_property;

    public function getProperty() {
        return $this->_property;
    }

    public function setProperty($value) {
        $this->_property = $value;
    }
}

class Controller {
    public function indexAction() {
        $id = 1;
        $mapper = new DataMapper();
        $data = $mapper->find($id); //--> returns if found a Data-Object
    }
}
Tobias Golbs
  • 4,586
  • 3
  • 28
  • 49
  • -1: that is not data mapper, your "controller" has been tightly coupled the said `DataMapper` class and mappers do not store/retrieve value objects. – tereško Jul 27 '13 at 09:24
  • @tereško Well this is the exact same way it is done in Zend Framework 1.x. So they do not use valid MVC? And the controller only passes the data to the model. What is wrong with this? – Tobias Golbs Jul 27 '13 at 09:27
  • @TobiasKun erm, ZF1 has no DataMappers or ORM at all. They have TableDataGateways, which return record sets. They don't return Value Objects, nor Entities. – Gordon Jul 27 '13 at 09:33
  • @Gordon: And in the quickstart they added the mapper as an abstraction layer that interacts with the TableDataGateway and converts the returned record sets to VOs. – Tobias Golbs Jul 27 '13 at 09:49
  • Ah, that might be. I haven't looked in the quickstart in a looooong time. It certainly wasn't in there when I first picked up ZF. But even if, it's not VOs (in the DDD & POEAA sense) and having an additional service layer between the controller and the mapper surely helps keeping business logic out of the controller, which is part of the presentation layer and should be exchangable without having to rewrite any queries. Of course, you can omit that service layer for pragmatic reasons if you are aware of the implications. – Gordon Jul 27 '13 at 10:01