Vous avez probablement entendu parler du modèle de graisse / du contrôleur mince contre une distinction mince modèle / contrôleur de graisse. J'ai récemment entendu dire que vous pouvez avoir quelque chose entre l'endroit où une partie de la logique du modèle passe dans une couche de service. Comme c'est courant? Et connaissez-vous (ou peut penser à) tous les exemples réels qui l'illustrent?
3 Réponses :
Martin Fowler décrit le Couche de service modèle de son excellent livre motifs de l'architecture d'applications d'entreprise . Si vous vous souciez de questions telles que celle que vous avez posées, vous devriez lire ce livre.
Une utilisation qui me vient à mon esprit est la couche de service em> est une solution pour cela, car c'est la couche dans laquelle vous pouvez Commencez et commettre un travail impliquant plusieurs modèles de domaine. P> Quant à la fréquence commune, je ne pense pas que ce soit commun du tout. La plupart des gens utilisant Zend Cadre (ou tout autre cadre PHP ou Ruby) sont à peine déplacés à peine de «l'enregistrement actif résout tout» au nouveau brillant », résout tout. Il semble que cette communauté n'apprend qu'un nouveau modèle tous les cinq ans. Ils n'arriveront pas à la couche de service pendant un moment. P> Re commentaire de @ktunik: p> Non, le modèle de couche de service est différent du motif de référentiel. Le référentiel concerne l'accès à la base de données d'abstraction afin que vous puissiez utiliser une base de données comme une collection. La couche de service consiste à encapsuler des opérations d'application complexes. P> Une autre façon de penser à eux est leur relation avec le modèle de domaine. Le référentiel est utilisé entre le modèle de domaine et la base de données. ATTENDU QUE la couche de service utilise un ou plusieurs modèles de domaine. P>
Service Layer ---> Domain Model(s) ---> Repository ---> DBAL
Une autre chose qui me confondue habituellement .. Couche de service et référentiel. Est-ce la même chose ou la même chose? Merci
La couche de service Le plaidoyer est relativement nouveau et toujours soumis à une variété d'interprétations. Je pense que cela signifie avoir une couche qui exploite plusieurs modèles de domaine que les contrôleurs appellent (je pourrais la simplifier trop). J'ai récemment développé un site Web en utilisant cet avantage et des avantages pratiques que j'ai rencontrés sont:
Caractéristiques en tant que service aide à l'évolutivité. Si vous avez un service d'image qui utilise initialement le service local pour le faire, il devient plus facile de disposer de ce point de service sur un autre serveur ou de la 3ème partie sans avoir à faire des mises à jour de balayage
flexibilité. À mi-chemin du projet, j'ai décidé de changer de fonctionnalité de base et j'ai été capable de le faire sans douleur; me permettant de peser rapidement les avantages et les inconvénients de la mise à jour. Cette flexibilité est utile lors du prototypage rapide et instille une certaine confiance, car si vous devez revisiter quelque chose, cela ne sera pas un cauchemar.
Extensibilité. J'ai déjà identifié des services dans mon application ce que je peux renaître à ouvrir à d'autres développeurs ou à d'autres widgets, applications mobiles à l'avenir. Ce faisant en théorie est juste une question d'ajout d'une authentification et d'une autorisation au service (car les fonctionnalités sont déjà dans sa propre couche et je n'ai pas à passer du temps à essayer de découpler ce que je veux exposer du reste de la base de code ).
Les services sont faciles à ajouter et à tomber (peut-être que cela appartient à l'un des points antérieurs). J'ai des services spécifiques à une étape spécifique du projet (par exemple, inviter uniquement la scène) que je peux chuter une fois que cette phase est terminée.
Je pense que cela a des avantages pratiques et une clé du succès de la mise en œuvre a un bon moyen de gérer les services dans la demande. J'utilise Symfony's composant d'injection de dépendance
Re # 2, pouvez-vous donner un exemple concret de la façon dont vous avez changé ce morceau de fonctionnalité (l'avant et après) juste pour qu'il soit plus facile de comprendre comment une couche de service fonctionne de manière pratique? Dans N ° 3, vous semblez que vous parlez d'une API et que # 4 sonne comme un système d'autorisation. J'essaie toujours d'obtenir ce que cette couche de service est à peu près et la bonne façon de l'utiliser, alors peut-être que c'est pourquoi je suis de retour sur ces concepts plus connus.
2. Je suis passé à partir de Solr vers MySQL et de retour sans impact sur mes modèles ni mes contrôleurs. (En fait, j'attends la doctrine de la mise en œuvre de la MongoDB de Doctrine pour mûrir un peu avant de donner une allée et c'est pourquoi j'ai mentionné que cela contribue à renforcer la confiance.
3. Je parle de faire de certains de mes services à la disposition des Devs tiers ou même de mes propres applications mobiles ou d'autres moyens de consommer le contenu.
4. J'utilise comme exemple pour montrer que tirer parti d'une couche de service facilite l'ajout ou soustraire la fonctionnalité (peut-être la même chose que le point 2). Mais je suis capable d'ajouter ou de soustraire des services sans que toute mon application soit échoue. Par exemple. J'ai un service d'invitation que je puisse simplement sortir en supprimant de la configuration et que l'application continuera à courir bien.
Voir Zfengine C'est CMF sur ZF avec la réalisation de la couche de service
Hmvc? Contrôleur de vue de modèle hiérarchique?
@ Walterj89 aha, merci pour le terme. Savez-vous qui est venu avec ça?
Je ne suis pas sûr de savoir qui est venu avec ça. Je me souviens juste de cela de la documentation de Kohanaphp. KohaNaframework.org Je suis familial avec MVC mais la partie H est toujours sur ma liste TOLEARN.