Multi-Tier dans le bon sens PHP..the?

Question

J'ai une question spécifique, qui pourrait utiliser une réponse générale ... Lors de la construction des applications multi-niveaux en PHP, tout doit-il être fait dans la couche logique métier, ou peut toute couche travailler ... Exemple, Disons que je construis une application qui affiche des informations utilisateur (à partir de la base de données) sur la couche de présentation. Dois-je utiliser la couche d'affaires pour passer simplement les données à la couche de présentation, ou tout simplement obtenir les informations de la base de données directement dans la couche de présentation. la couche de présentation doit être utilisé juste pour la présentation des données, la couche accesseur utilisé juste pour obtenir les données, et tout le travail se fait dans la couche d'affaires?

En outre, en parlant des différentes couches, est-il préférable de faire les choses de la procédure, ou à l'aide POO (comme l'utilisation comprend pour montrer les modèles vs en utilisant une classe pour inclure les modèles, la validation des données procédure vs utilisation d'une classe ou fonctions vs classes pour obtenir les données de la base de données, etc.)

Comme vous pouvez le voir, je suis en train de comprendre comment les choses fonctionnent, et la meilleure façon de faire les choses. Cela étant dit, si vous avez des conseils ou des conseils généraux sur le sujet ... s'il vous plaît laissez ..

Merci

Answer 1

applications Web et N-tier est intéressant, surtout parce que la notion de N-tier a élargi avec l'adoption généralisée de JSON et AJAX ou Flash et XMLRPC. Cette sur Webopedia affiche une ligne bleue décalée qui exprime bien. Pour résumer: votre entreprise, accesseur, et la logique de présentation pourrait non seulement exister sur le serveur - mais dans certains cas, directement dans le navigateur. L'intention de N-tier, cependant, est séparabilité . Si vous avez besoin de changer votre interface utilisateur ou votre base de données, ou ajouter d'autres interfaces, vous ne devriez pas affecter votre logique métier. Et voici ce qui déterminera votre API -. Anticiper le jour où votre HTML et CSS sont mis au rebut pour Flex et MySQL est changé pour Oracle

Il est exigences déterminées, et dans certaines applications Web que je l'ai utilisé, les variations de N-tier sont utilisés simultanément. Prenons par exemple LyrisHQ (e-mail ASP). Ils ont une application web client. Récemment, ils ont regardé pousser leur application Flash. Ceci est clairement expédition beaucoup communicabilité de données au navigateur, et il y a probablement un peu de logique métier en double dans l'interface utilisateur Flash. Ils doivent maintenir les deux applications, cependant, étant donné que l'un est nécessaire pour des exigences différentes (et qui se chevauchent).

les plus courantes des applications PHP ne considèrent pas l'expédition beaucoup de données non formatées au navigateur. Mais si vous étiez, cela vous informer très rapidement comment vous voulez concevoir vos API. Très probablement, vous voulez les contrôleurs qui pourraient parler XMLRPC, REST ou SOAP ... en plus d'une même classe de contrôleur interne que vos modèles de présentation PHP utilisés. Cela strictement signifie pour une simple page de connexion web, vous auriez un modèle de PHP pour le formulaire de connexion qui parlait à une classe de LoginController. Une interface XML serait également utiliser la même classe LoginController. Tout comme vous supposez que vous seriez Bonkers d'écrire SQL dans une requête Ajax ... vous seriez d'éviter strictement l'écriture des requêtes dans vos modèles de présentation.

couches d'entreprises peuvent être plus ou moins stricte, parce que souvent il n'y a jamais besoin de changer de marque de base de données back-end. Dans une conception stricte N-tier, comment vos objets métier parleraient à votre base de données serait comme si vous pouvez passer de MySQL à MS SQL sans réécrire le niveau d'affaires. Parfois, cela se fait par des objets de modélisation pour chaque table (table porte d'entrée), chaque rangée (enregistrement actif), chaque jointure, ou chaque transaction. C'est là quelque chose comme AOP ou PHP-ADO sont utiles, mais insuffisantes pour l'isolement complet. ORM / couches de persistance Java comme Hibernate montrent mieux ce genre d'isolement, souvent en fournissant un objet Query Language (OQL).

Moi-même, je suis entreprend actuellement une transition arrière-plan à partir d'une application PHP basée sur MySQL à un MS-SQL un. L'application n'a jamais utilisé des requêtes SQL directes. Imaginez choisir comment prendre une série de requêtes dans une classe et soit les abstraire, ou sous-classement, et nous espérons ne pas modifier la logique métier. Au minimum, vous voulez faire tous vos appels SQL indirecte. ( S.O. message sur PHP ORM .)

Et enfin, à votre question sur la POO: comment l'utiliser, vous devez pour répondre à vos besoins. Ma technique personnelle est de commencer avec la logique droite un modèle de présentation de PHP pendant quelques minutes pour obtenir le roulement à billes, très bientôt je vais Refactoriser que dans une classe et un modèle. Si j'ai des idées communes, je briserai des routines en classes partagées, cherchant à préserver le principe de DNRY. ( SO poster sur ici. OOP est pas une exigence fondamentale pour la conception N-tier. DNRY est très important pour garder votre code maintenable, tho. dedix délais et la portée de décalage destroy une API. Refactoriser jusqu'à ce que vous obtenez ce que vous devez continuer. Je parie que POO vous aidera à arriver.

Answer 2

J'ai lu quelque chose en disant que les grands modèles (couche d'affaires) devraient être préférés aux grands contrôleurs (couche accesseur).

Aussi: Cela dépend vraiment du projet. A mes yeux, il n'a pas toujours judicieux d'utiliser OOP pour tout (probablement pas tout le monde sera d'accord ici), en particulier dans les langages de script comme PHP, il est souvent plus facile de faire simplement validateurs comme fonctions ...

Answer 3

Je conseille vraiment vous ne pas avoir des appels de base de données dans la couche de présentation, qui irait à l'encontre de son but.

Il existe différentes approches architecture multi-niveaux et ils ont des recommandations différentes.

Zend Framework que j'ai travaillé avec est généralement de la forme modèle Fat / variante du contrôleur mince.

Si trouver cet article Remarques sur le choix d'un cadre de PHP pour être assez bon à comparer (dans ce cas) CakePHP à Zend Framework.

La plus grande différence dans mon opionion est l'approche convention-sur-configuration prise par CakePHP, qui est très différente de mise au point de configuration dans Zend Framework.

En utilisant un cadre, ce qui fait beaucoup de sens si la mise en œuvre d'une architecture à plusieurs niveaux, vous êtes d'une manière forcée ou tout au moins poussé dans l'utilisation POO, ce qui est une mauvaise chose.

Vous pouvez bien sûr mettre en œuvre, par exemple une architecture à 3 niveaux avec des appels fonctionnels purs, mais il ne serait pas scalable que bien après mon expérience.

Pour un site Web le modèle MVC qui est en fait tout à fait différente en raison de la façon dont les niveaux communiquent, est un bon choix.

La différence entre un « normal » arc à 3 niveaux et le modèle MVC est que le point de vue a accès à la fois le contrôleur et la couche du modèle, alors que la couche de présentation ne dispose que d'un accès à la couche de logique de la 3-tier arc.

Answer 4

Je suis d'accord avec ce que Franz a dit, en particulier sur préférant les modèles plus grands sur les contrôleurs plus grands .. vous pouvez également utiliser une règle de base pour aider à distinguer où le code devrait aller: si elle n'a rien à voir avec la structure de l'interface utilisateur / flux, mettre dans le contrôleur; si elle est pure logique commerciale, il va dans le modèle ..

Je vais ajouter qu'en tant que développeur Java qui avait beaucoup d'expérience avec Struts avant de tester les eaux PHP, il m'a fallu un certain temps pour comprendre comment appliquer les idées MVC à un langage de script .. Personnellement, je trouve que l'utilisation un système comme CodeIgnitor beaucoup aidé .. il fournit le cadre, tout comme Struts, et encourage les bonnes habitudes MVC ..

Answer 5

Mon monde ressemble à ceci:

  

DB1 <- Model1 pour fournir accesseur   fonctions, l'intégrité des données, les entreprises   règles pour ce DB2 jeu de données <- Model2   de fournir des fonctions d'accès, des données   l'intégrité, les règles commerciales pour cette   ensemble de données

     

Contrôleur: Contrôle de flux de données   vues, filtres / données provenant organise   vues. Met en œuvre des règles d'affaires pour   l'application donnée . connaît la   règles métier entre Modèles.

     

Vues: Rien de plus que des modèles   que les données d'affichage fournies par le   Manette. Passez toutes les données à la   manette. N'a pas connaissance de   Model1 ou Model2 ou l'entreprise   la logique qui les régit.

Answer 6

Je recommande de faire des recherches sur les modèles de conception que c'est la pièce manquante de votre puzzle. Il y a un certain nombre de livres spécifiques à PHP qui couvrent ce sujet (ceux de AAppuyez sont bonnes), ainsi que la « bible » des modèles de conception: "noreferrer design Patterns: Elements de logiciel orienté objet réutilisable"

Answer 7

Attendons la version plus stable de Doctrine2 .

Il est développé avec la persistance ignorant la philosophie objet de domaine. Il sera beaucoup plus facile de développer des applications multi-niveaux avec l'aide de ce cadre.