Bon Référentiel de Conception de Modèle en PHP?

Je pensais prendre une fissure à répondre à ma propre question. Ce qui suit est juste une façon de résoudre les questions 1 à 3 dans ma question initiale.

Avertissement: je ne peut pas toujours utiliser les bons termes lors de la description des modèles ou techniques. Désolé pour ça.

Les Objectifs:

• Créer un exemple complet d'un contrôleur de base pour la visualisation et l'édition de Users.
• Tout le code doit être entièrement vérifiés et mockable.
• Le contrôleur doit avoir aucune idée de l'endroit où sont stockées les données (ce qui signifie qu'il peut être changé).
• Exemple pour montrer un SQL de mise en œuvre (les plus courantes).
• Pour des performances maximales, les contrôleurs devraient recevoir uniquement les données dont ils ont besoin—pas de champs supplémentaires.
• Mise en œuvre devrait tirer parti de certains type de mapper des données pour faciliter le développement.
• Mise en œuvre devrait avoir la capacité d'exécuter le complexe de données de recherches.

La Solution

Je vais partager mon stockage persistant (base de données) de l'interaction en deux catégories: R (Lire) et CUD (Create, Update, Delete). Mon expérience a été que les lectures sont vraiment quelles sont les causes d'une demande de ralentir. Et tandis que la manipulation de données (CUD) est en fait plus lentement, il se passe beaucoup moins souvent, et est donc beaucoup moins d'inquiétude.

CUD (Create, Update, Delete) est facile. Ceci implique une collaboration avec le réel modèles, qui sont ensuite transmis à mon Repositories pour la persistance. Remarque, mon référentiels de toujours fournir une méthode de Lecture, mais simplement pour la création d'objet, pas d'affichage. Plus sur cela plus tard.

R (Lu) n'est pas si facile. Pas de modèles ici, juste des objets de valeur. Utiliser des tableaux de si vous préférez. Ces objets peuvent représenter un modèle unique ou un mélange de plusieurs modèles, n'importe quoi vraiment. Ces ne sont pas très intéressantes sur leur propre, mais comment ils sont générés à l'est. J'utilise ce que j'appelle Query Objects.

Le Code:

Modèle Utilisateur

Commençons simple avec notre base de modèle d'utilisateur. Notez qu'il n'y a pas d'ORM extension ou la base de données des trucs à tous. Juste pur modèle de gloire. Ajouter votre getters, setters, de validation, de quoi que ce soit.

class User
{
    public $id;
    public $first_name;
    public $last_name;
    public $gender;
    public $email;
    public $password;
}

Référentiel De L'Interface

Avant que je créer mon dépôt, je veux créer mon référentiel de l'interface. Cela permettra de définir le "contrat" que les référentiels doivent suivre dans l'ordre pour être utilisé par mon contrôleur. Rappelez-vous, mon contrôleur ne sais pas où les données sont stockées.

Remarque que mon référentiels que tous contiennent ces trois méthodes. Le save() méthode est à la fois responsable de la création et de la mise à jour des utilisateurs, tout simplement en fonction de si oui ou non l'objet utilisateur a un identifiant.

interface UserRepositoryInterface
{
    public function find($id);
    public function save(User $user);
    public function remove(User $user);
}

SQL Référentiel de mise en Œuvre

Aujourd'hui de créer mon implémentation de l'interface. Comme mentionné, mon exemple ne pouvait être qu'avec une base de données SQL. Notez l'utilisation d'une mapper des données pour éviter d'avoir à écrire répétitif des requêtes SQL.

class SQLUserRepository implements UserRepositoryInterface
{
    protected $db;

    public function __construct(Database $db)
    {
        $this->db = $db;
    }

    public function find($id)
    {
        //Find a record with the id = $id
        //from the 'users' table
        //and return it as a User object
        return $this->db->find($id, 'users', 'User');
    }

    public function save(User $user)
    {
        //Insert or update the $user
        //in the 'users' table
        $this->db->save($user, 'users');
    }

    public function remove(User $user)
    {
        //Remove the $user
        //from the 'users' table
        $this->db->remove($user, 'users');
    }
}

Objet De Requête De L'Interface

Maintenant avec CUD (Create, Update, Delete) pris en charge par notre référentiel, nous pouvons nous concentrer sur la R (Lire). Les objets de requête sont tout simplement une encapsulation de certains types de données logique de recherche. Ils sont pas générateurs de requêtes. En faisant abstraction comme notre référentiel, nous pouvons changer la mise en oeuvre et tester plus facilement. Un exemple d'un Objet de Requête peut être un AllUsersQuery ou AllActiveUsersQuery, ou même MostCommonUserFirstNames.

Vous pensez peut-être "je ne peux pas juste de créer des méthodes dans mes dépots à ces requêtes?" Oui, mais ici, c'est pourquoi je ne le fais pas:

• Mes dépôts sont conçus pour travailler avec des objets de modèle. Dans un monde réel, app, pourquoi aurais-je besoin pour obtenir le password si je suis à la recherche de la liste de tous mes utilisateurs?
• Les dépôts sont souvent des modèles spécifiques, mais les requêtes impliquent souvent plus d'un modèle. Donc, ce référentiel ne vous mettez votre méthode?
• Ce qui me permet de garder des référentiels très simple—pas de ballonnement classe de méthodes.
• Toutes les requêtes sont désormais organisés dans leurs propres classes.
• Vraiment, à ce stade, les référentiels existent tout simplement abstraction de ma couche de base de données.

Pour mon exemple, je vais créer un objet de requête de recherche "AllUsers". Voici l'interface:

interface AllUsersQueryInterface
{
    public function fetch($fields);
}

Objet De Requête De Mise En Œuvre

C'est là que nous pouvons utiliser un mappeur de données de nouveau pour aider à accélérer le développement. Notez que je suis en permettant un réglage pour le retour de l'ensemble de données—les champs. C'est à peu près aussi loin que je veux aller à la manipulation de la requête. Souvenez-vous, mes objets de requête ne sont pas générateurs de requêtes. Ils suffit d'effectuer une requête spécifique. Cependant, depuis que je sais que je vais probablement utiliser beaucoup celle-ci, dans un certain nombre de situations différentes, je me donne la possibilité de spécifier les champs. Je ne veux plus jamais retourner les champs je n'ai pas besoin!

class AllUsersQuery implements AllUsersQueryInterface
{
    protected $db;

    public function __construct(Database $db)
    {
        $this->db = $db;
    }

    public function fetch($fields)
    {
        return $this->db->select($fields)->from('users')->orderBy('last_name, first_name')->rows();
    }
}

Avant de passer à la manette, je veux montrer un autre exemple pour illustrer la puissance de ce qui est. J'ai peut-être un moteur de génération de rapports et la nécessité de créer un rapport pour AllOverdueAccounts. Ce qui peut être délicat avec mon mapper des données, et je veux écrire un SQL dans cette situation. Pas de problème, voici ce que cet objet de requête pourrait ressembler à:

class AllOverdueAccountsQuery implements AllOverdueAccountsQueryInterface
{
    protected $db;

    public function __construct(Database $db)
    {
        $this->db = $db;
    }

    public function fetch()
    {
        return $this->db->query($this->sql())->rows();
    }

    public function sql()
    {
        return "SELECT...";
    }
}

Ce bien garde toute ma logique pour ce rapport dans une classe, et il est facile de tester. Je peux moquer de mon cœur le contenu, ou même utiliser une mise en œuvre différente entièrement.

Le Contrôleur

Maintenant la partie amusante—rassembler tous les morceaux ensemble. Notez que je suis à l'aide de l'injection de dépendance. Généralement, les dépendances sont injectés dans le constructeur, mais je préfère de les injecter dans mes méthodes de contrôleur (routes). Cela réduit le contrôleur de l'objet graphique, et je trouve cela plus lisible. Remarque, si vous n'aimez pas cette approche, il suffit d'utiliser la traditionnelle méthode de constructeur.

class UsersController
{
public function index(AllUsersQueryInterface $query)
{
//Fetch user data
$users = $query->fetch(['first_name', 'last_name', 'email']);
//Return view
return Response::view('all_users.php', ['users' => $users]);
}
public function add()
{
return Response::view('add_user.php');
}
public function insert(UserRepositoryInterface $repository)
{
//Create new user model
$user = new User;
$user->first_name = $_POST['first_name'];
$user->last_name = $_POST['last_name'];
$user->gender = $_POST['gender'];
$user->email = $_POST['email'];
//Save the new user
$repository->save($user);
//Return the id
return Response::json(['id' => $user->id]);
}
public function view(SpecificUserQueryInterface $query, $id)
{
//Load user data
if (!$user = $query->fetch($id, ['first_name', 'last_name', 'gender', 'email'])) {
return Response::notFound();
}
//Return view
return Response::view('view_user.php', ['user' => $user]);
}
public function edit(SpecificUserQueryInterface $query, $id)
{
//Load user data
if (!$user = $query->fetch($id, ['first_name', 'last_name', 'gender', 'email'])) {
return Response::notFound();
}
//Return view
return Response::view('edit_user.php', ['user' => $user]);
}
public function update(UserRepositoryInterface $repository)
{
//Load user model
if (!$user = $repository->find($id)) {
return Response::notFound();
}
//Update the user
$user->first_name = $_POST['first_name'];
$user->last_name = $_POST['last_name'];
$user->gender = $_POST['gender'];
$user->email = $_POST['email'];
//Save the user
$repository->save($user);
//Return success
return true;
}
public function delete(UserRepositoryInterface $repository)
{
//Load user model
if (!$user = $repository->find($id)) {
return Response::notFound();
}
//Delete the user
$repository->delete($user);
//Return success
return true;
}
}

Réflexions Finales:

Les choses importantes à noter ici sont que lorsque je fais des modifications (création, mise à jour ou suppression) d'entités, je suis en train de travailler avec de vrais objets de modèle, et l'accomplissement de la persistance à travers mes dépôts.

Cependant, quand je suis à l'affichage (sélection des données et de les envoyer sur le point de vue) je ne travaille pas avec des objets de modèle, mais plutôt de la plaine de vieux objets de valeur. Je sélectionner uniquement les champs dont j'ai besoin, et il est conçu de sorte que je peux au maximum mes données de recherche de performance.

Mon dépôts séjour très propre, et, au lieu de ce "désordre" est organisé dans mon modèle de requêtes.

- Je utiliser un mappeur de données à l'aide au développement, comme c'est juste ridicule d'écrire répétitif SQL pour les tâches courantes. Cependant, vous ne pouvez absolument écrire de SQL en cas de besoin (les requêtes compliquées, rapports, etc.). Et quand vous faites, il est bien rangé dans un bien nommé de la classe.

J'aimerais entendre votre point de vue sur mon approche!

---

Juillet 2015 Mise À Jour:

J'ai été demandé dans les commentaires, où j'ai fini avec tout ça. Eh bien, pas ce qui loin en fait. Honnêtement, je n'ai toujours pas vraiment comme les référentiels. Je les trouve exagéré pour la base de recherches (surtout si vous utilisez déjà un ORM), et malpropre lorsque l'on travaille avec les questions plus complexes.

Je travaille généralement avec un ActiveRecord style de l'ORM, de sorte que le plus souvent je vais juste référence à ces modèles, directement dans mon application. Toutefois, dans les cas où j'ai des requêtes plus complexes, je vais utiliser des objets de requête, à les rendre plus réutilisable. Je dois aussi préciser que j'ai toujours injecter mes modèles dans mes méthodes, ce qui rend plus facile de se moquer de mes tests.

- Je utiliser les interfaces suivantes:

• Repository - charges, des insertions, des mises à jour et supprime les entités
• Selector - trouve des entités basées sur les filtres, dans un référentiel
• Filter - encapsule la logique de filtrage

Mon Repository est à la base de données agnostique; en fait, il ne précisez pas la persistance; il pourrait être n'importe quoi: la base de données SQL, xml, services à distance, un alien de l'espace etc.
Pour les capacités de recherche, la Repository construit une Selector qui peuvent être filtrés, LIMIT-ed, triés et comptés. En fin de compte, le sélecteur récupère une ou plusieurs Entities de la persistance.

Voici un exemple de code:

<?php
interface Repository
{
public function addEntity(Entity $entity);
public function updateEntity(Entity $entity);
public function removeEntity(Entity $entity);
/**
* @return Entity
*/
public function loadEntity($entityId);
public function factoryEntitySelector():Selector
}
interface Selector extends \Countable
{
public function count();
/**
* @return Entity[]
*/
public function fetchEntities();
/**
* @return Entity
*/
public function fetchEntity();
public function limit(...$limit);
public function filter(Filter $filter);
public function orderBy($column, $ascending = true);
public function removeFilter($filterName);
}
interface Filter
{
public function getFilterName();
}

Ensuite, une mise en œuvre:

class SqlEntityRepository
{
...
public function factoryEntitySelector()
{
return new SqlSelector($this);
}
...
}
class SqlSelector implements Selector
{
...
private function adaptFilter(Filter $filter):SqlQueryFilter
{
return (new SqlSelectorFilterAdapter())->adaptFilter($filter);
}
...
}
class SqlSelectorFilterAdapter
{
public function adaptFilter(Filter $filter):SqlQueryFilter
{
$concreteClass = (new StringRebaser(
'Filter\\', 'SqlQueryFilter\\'))
->rebase(get_class($filter));
return new $concreteClass($filter);
}
}

La ideea est que le générique Selector utilise Filter mais la mise en œuvre SqlSelector utilise SqlFilter; la SqlSelectorFilterAdapter s'adapte générique Filter pour un béton SqlFilter.

Le code client crée Filter objets (qui sont des filtres génériques), mais dans le concret de la mise en œuvre du sélecteur de ces filtres sont transformés en SQL filtres.

Autres sélecteur implémentations, comme InMemorySelector, transformer de Filter à InMemoryFilter à l'aide de leurs InMemorySelectorFilterAdapter; de la sorte, chaque sélecteur de mise en œuvre est livré avec son propre adaptateur de filtre.

À l'aide de cette stratégie de mon code client (dans le bussines couche) ne se soucie pas d'un référentiel spécifique ou le sélecteur de mise en œuvre.

/** @var Repository $repository*/
$selector = $repository->factoryEntitySelector();
$selector->filter(new AttributeEquals('activated', 1))->limit(2)->orderBy('username');
$activatedUserCount = $selector->count(); //evaluates to 100, ignores the limit()
$activatedUsers = $selector->fetchEntities();

P. S. C'est une simplification de mon vrai code

Je ne peux commenter sur la façon dont nous (à mon entreprise) face à cela. Tout d'abord la performance n'est pas trop un problème pour nous, mais en ayant propre/bon code.

Tout d'abord, nous définissons les Modèles comme un UserModel qui utilise un ORM pour créer UserEntity objets. Lorsqu'un UserEntity est chargé à partir d'un modèle de tous les champs sont chargés. Pour les champs de référencement des entités étrangères nous utiliser le modèle étranger à créer des entités respectives. Pour ces entités, les données seront chargés à la demande. Maintenant, votre première réaction pourrait être ...???...!!! laissez-moi vous donner un exemple un peu un exemple:

class UserEntity extends PersistentEntity
{
public function getOrders()
{
$this->getField('orders'); //OrderModel creates OrderEntities with only the ID's set
}
}
class UserModel {
protected $orm;
public function findUsers(IGetOptions $options = null)
{
return $orm->getAllEntities(/*...*/); //Orm creates a list of UserEntities
}
}
class OrderEntity extends PersistentEntity {} //user your imagination
class OrderModel
{
public function findOrdersById(array $ids, IGetOptions $options = null)
{
//...
}
}

Dans notre cas $db est un ORM qui est capable de charger les entités. Le modèle indique à l'ORM pour charger un ensemble d'entités d'un type spécifique. L'ORM contient une cartographie et l'utilise pour injecter tous les champs pour que l'entité de l'entité. Pour les étrangers champs, cependant, seulement l'identité de ces objets sont chargés. Dans ce cas, le OrderModel crée OrderEntitys avec seulement l'id de référence des commandes. Lorsque PersistentEntity::getField est appelée par la OrderEntity l'entité indique c'est le modèle à chargement différé tous les champs dans la OrderEntitys. Tous les OrderEntitys associé à un UserEntity sont traités comme un seul résultat et sera chargé à la fois.

La magie ici, c'est que notre modèle et ORM injecter toutes les données dans les entités, et que les entités fournissent simplement des fonctions wrapper pour le générique getField méthode fournie par PersistentEntity. Pour résumer, nous avons toujours charger tous les champs, mais les champs de la référence d'une entité étrangère sont chargés lorsque nécessaire. Juste le chargement d'un tas de champs n'est pas vraiment un problème de performance. Charge possible des entités étrangères mais serait une ÉNORME baisse de la performance.

Maintenant sur le chargement d'un ensemble spécifique d'utilisateurs, fondée sur une clause where. Nous fournissons un objet orienté ensemble de classes qui vous permettent de spécifier simple expression qui peuvent être collées ensemble. Dans l'exemple de code que j'ai nommé GetOptions. C'est un wrapper pour toutes les options possibles pour une requête select. Il contient un ensemble de clauses where, group by et tout le reste. Notre où les clauses sont assez complexes, mais vous pouvez bien évidemment faire une version plus simple facilement.

$objOptions->getConditionHolder()->addConditionBind(
new ConditionBind(
new Condition('orderProduct.product', ICondition::OPERATOR_IS, $argObjProduct)
)
);

Une version plus simple de ce système serait de passer le cas OÙ une partie de la requête comme une chaîne de caractères directement sur le modèle.

Je suis désolé pour cette très compliqué de réponse. J'ai essayé de résumer notre cadre le plus rapidement et clairement possible. Si vous avez des questions supplémentaires, n'hésitez pas à demander et je vais mettre à jour ma réponse.

EDIT: de plus, si vraiment vous ne voulez pas charger certains domaines, tout de suite, vous pouvez spécifier un chargement différé option dans votre ORM cartographie. Parce que tous les champs sont finalement chargé par le getField méthode, vous pouvez charger certains champs de dernière minute lorsque cette méthode est appelée. Ce n'est pas un très gros problème en PHP, mais je ne recommanderais pas pour les autres systèmes.

Je suggère https://packagist.org/packages/prettus/l5-repository en tant que vendeur à mettre en œuvre des Référentiels/Critères etc ... dans Laravel5 😀