[RFC] Converting Active Record to the Data Mapper pattern #12317

SidRoberts · 2016-10-14T09:30:59Z

So I thought I'd have a go at converting Phalcon's Active Record models to the Data Mapper pattern (see Doctrine) and I want to hear people's thoughts and opinions before I take it any further.

I've avoided doing to much work just in case it ends up being a dead-end so no code has been refactored and methods in the models manager now call protected methods in Phalcon\Mvc\Model, etc; - it's a bit of a mess. Obviously this will/should all change.

Put succinctly, methods have been moved to the models manager and (currently) operate exactly as they did before:

// Before
$person = People::findFirst($params);

// After
$person = $modelsManager->findFirst(
    People::class,
    $params
);

// Before
$person = People::count($params);

// After
$person = $modelsManager->count(
    People::class,
    $params
);

// Before
$person->delete();

// After
$modelsManager->delete($person);

// Before
$person->save($params);

// After
$modelsManager->save($person, $params);

Phalcon\Mvc\Model is still far too complicated, in my opinion, so there's still a lot of work to do. 😛

A few things that I'd like to do is remove the ability to assign properties during create/update/save:

$robot->save(
    [
        "name" => "Bender",
    ]
);

$modelsManager->save(
    $robot,
    [
        "name" => "Bender",
    ]
);

I know people like it because it acts a little shortcut but it doesn't make sense in the data mapper context and looks a little clumsy. A method called save() should save and do nothing else.

I'd also like to decide between only supporting public properties or getters/setters but have no personal preference of either. Alternatively (or additionally), make an effort to vastly simplify how properties are get/set internally.

(It goes without saying but is obviously aimed at version 4 - not version 3)

Thoughts?

Jurigag · 2016-10-14T09:37:04Z

Introduce please repository class imho as well, because using modelsManager is dirty. So we can still jus t do $personRepostory->find(); for example. Like some abstract class:

abstract class ModelRepository
{
 // all find methods, as well findFirstById, and findFirstBy*, etc, just all finds which are currently in model, as well sum, count etc things
    abstract public funciton setSource(); // which will return Person::class for example in PersonRepository, this will be used for all selections
}

Or eventually this should be used in model like $this->setRepository(new PersonRepository()) in initialize method, and then we can do something like $modelsManager->getRepository(Person::class)->find(); With option to use some alias so we don't need to use Person::class we could just use for example M:Person.

And then totally remove this _invokeFinder imho and only repostiories for selection.

Also we should aim for totally removing Phalcon\Mvc\Model, eventually it can stay there and give ability to like assign, validation and other stuff but extending should not be needed for working with models manager and data mapper.

Also repository classes will be good one place for adding all custom related model find methods, so somewhere in code instead of executing some extensive find or query we can just call proper method - this is pretty main reason im asking for it, just built-in repository class with some generic methods in it + option to add our own.

Don't know which way is better, i guess second.

Also this change is of course for 4.0.0. I thought @andresgutierrez was planning this for 4.0.0

I would need to rewrite whole app then because im using everywhere $model->save($params, $whiteList) because it's really super great.

sergeyklay

Looks great to me

Green-Cat · 2016-10-14T13:15:17Z

phalcon/mvc/model/manager.zep

+
+
+
+


Too much spacing.

I was going for speed. 😉

No need for speed, it will be at least few months until we create 4.0.x repo i guess, and few years to release :D

Fixed in 77acbfe.

Green-Cat · 2016-10-14T13:17:35Z

phalcon/mvc/model/manager.zep

+
+
+	/**
+	 * Allows to query the first record that match the specified conditions


Allows to query for the first record that matches the specified conditions

Fixed in 77acbfe.

SidRoberts · 2016-10-14T15:46:08Z

@Jurigag, it'd be tedious to have to create repository classes for each model. We could set the model class name in the constructor though:

namespace Phalcon\Mvc\Model;

class Repository
{
    public function __construct(string! modelClass);

    public function find(array params = []) -> <ResultsetInterface>;

    public function findFirst(array params = []) -> <ModelInterface>;

    public function count(array parameters = []) -> int;

    public function sum(array parameters = []);

    public function maximum(array parameters = []);

    public function minimum(array parameters = []);

    public function average(array parameters = []);
}

It would reduce the complexity of the Models Manager a bit but would repositories add complexity for users/developers?:

$robots = $modelsManager->findFirst(
    Robots::class,
    $params
);

// OR ...

$robotsRepository = $modelsManager->getRepository(
    Robots::class
);

$robots = $robotsRepository->findFirst($params);

Jurigag · 2016-10-14T16:22:12Z

I mean if you don't want - you don't need to create repository. You can use as well just $modelsManager->findFirst(Robots::class, $params) i guess maybe. Repository will be just some kind of shorthand and some place where you can add addtional methods for finding stuff. I know developer can always create his own class but in most Data Mappers there is Repository class introduced.

By using constructor it's fine. But what if we want to extend phalcon repository and use our own ? Then we need to point it somewhere, in model or in modelsmanager. SO:

We don't need to create repositories for each model and generic internal Repository will be used for each model. But still we will have in model something like $this->setRepository(new PersonRepository(self::class)) and this repository will be used.

Or eventually something like $modelsManager->registerRepository(new PersonRepository(Person::class))

I think second will be better so we can like remove totally need for people to extend Phalcon\Mvc\Model

So in total - i think there should be Repository class which will be used always. No matter if we create it or not. Just phalcon will create proper repository object if none provided by us.

I know that this can mean that there could be possible Phalcon\Mvc\Model\Repository for 10 models in some cases created.

Also models manager is already really complex enough. So introducing Repository will be better i think.

Jurigag

Phalcon/Mvc/Model/Repository class, add option to use custom Repository class for models.

Jurigag · 2016-10-14T16:43:57Z

phalcon/mvc/model/manager.zep

+		 */
+		let related = model->_related;
+		if typeof related == "array" {
+			if model->_preSaveRelatedRecords(writeConnection, related) === false {
