Zend FR

pour parler purement architecture de façon générale. cela s'applique à Zend mais à toute autre dev.

ce ne sont que des réflexions théoriques et doivent donc être adapté à la réalité du terrain.

l'approche de base pour faire une classe métier consiste souvent à créer une classe par entité disponible dans l'espace de stockage.

du coup très souvent on se retrouve avec un classe entité qui contient les attributs de l'entité les méthode d'accès au stockage et des méthodes de manipulation.

c'est déjà un bon point par rapport au fait de faire ça dans le contrôleur.

la première chose que l'on peut envisager alors c'est la séparation de la couche persistance de la couche métier.

la réflexion à mener alors est de faire la part entre ce qui est de la manipulation de l'entité d'un point de vu purement centrée sur elle même en écartant tout ce qui concerne la façon dont on va l'enregistrer.

la bonne question à se poser est QUOI dès qu'un COMMENT intervient il y a sûrement un danger.

en parvenant à faire cela correctement on a donc un ensemble de classe qui représente les entité qu'on va avoir dans la source de donnée. et un autre ensemble de classe qui vont décrire comment les premières s'insèrent dans la source de donnée.

c'est souvent un première bonne approche pour se familiariser avec la séparation des couches.

pour entrer dans les choses plus sérieuses il convient de prendre le problème dans l'autre sens.

Réfléchir aux concepts manipulés sans s'encombrer l'esprit de la façon dont on vas les stocker, ni même de la façon dont on va les utiliser.

en clair réfléchir de façon purement conceptuelle aux éléments qu'on manipules. User Facture planning livre rayon film etc.

cela donne des classes métiers qui ont des relations entre elles et qui forment une logique métier propre.

lorsqu'on à conceptualisé cela on se penche sur l'usage qu'on va en faire dans l'application
le fait de faire cette séparation permet de réutiliser les classes métier d'application en application.

un User reste un User quelque soit l'application, une Facture reste une Facture.

souvent la réflexion sur une application permet d'enrichir l'objet métier. il faut alors faire attention de ne pas le polluer de choses qui ne le concerne pas. si un ajout spécifique à l'appli doit impérativement être attaché à l'objet métier il faut envisager une association d'objet ou une classe dérivée.

de l'autre côté il convient de rassembler l'ensemble des classe métier à stocker dans la ou les sources de données et faire un modèle conceptuel de la base. il faut ensuite le décliner en modèle physique de la base.

les deux peuvent être très différent. le modèle physique doit tenir compte de l'usage qui sera fait pour optimiser les perfs. il est parfois intéressant de dé-normaliser un modèle pour le rendre lus efficace.

au contraire il convient par fois de normaliser. par exemple si j'ai un objet métier user qui contient nom, prenom, adresse, ville, cp, un autre société qui contient raison sociale nom capital ... et possède une liste d'adresse postale elle même définie comme adresse rue ville je peux très bien garder ainsi la modélisation conceptuelle de ma base et faire un modèle physique ou le user sera nom prenom et un lien sur une adresse postale.

il n'est pas nécessaire d'avoir adéquation exacte entre objet métier et espace de stockage.
un exemple mes user sont dans un annuaire LDAP qui ne contient pas l'adresse postale personnelle ma base RH contient une table adresse postale il me suffit de définir une table ldapuser dans ma base qui contient id LDAP de l'utilisateur et le lien sur l'adresse postale.

lorsque le modèle physique et prêt et le modèle métier aussi on peut passer à la persistance

on voit vite que pour un même modèle métier ci dessus la façon de lire et écrire en base entre mon exemple en base et celui avec LDAP sera complètement différent. les tables en base se seront pas exactement le reflét des classe métier

il ressort à la fin
un modèle métier pur
un modèle d'usage
un modèle physique de stockage
un modèle de persistance.

si vous parvenez à ça c'est très bien. mais il faut aussi être pragmatique dans la vie et suivant l'ampleur du projet son intégration dans un système plus vaste on peut se permettre de simplifier cela.

si le projet s'inscrit dans un Système d'information je vous conseille fortement de réfléchir ainsi non pas au sein de votre application mais en terme de système

les classe métier dégagés pour le système se retrouveront fatalement dans les applications
c'est donc une source importante pour le développement d'une application.

de plus en ayant une approche système on perçois mieux les enjeux d'évolution du système et on peut rendre sa modélisation plus adaptable (même si certaines appli mourront ou devront être adaptées)


A+JYT