Multi-Nivel de manera correcta PHP..the?

Question

Tengo una pregunta específica, que podría utilizar una respuesta general ... Cuando la construcción de aplicaciones de varios niveles en PHP, qué todo tiene que ser hecho en la capa de lógica de negocios, o puede hacer el trabajo de cualquier capa ... Ejemplo, digamos que estoy construyendo una aplicación que muestra la información del usuario (de la base de datos) en la capa de presentación. ¿Debo usar la capa de negocio simplemente pasar los datos a la capa de presentación, o simplemente obtener la información de la base de datos directamente dentro de la capa de presentación. En caso de que la capa de presentación puede utilizar apenas para la presentación de los datos, la capa de acceso utilizados sólo para obtener los datos, y todo el trabajo se hará en la capa de negocio?

Además, al hablar de las diferentes capas, es que lo mejor es hacer las cosas de procedimiento, o el uso de programación orientada a objetos (como usar incluye para mostrar las plantillas vs usando una clase para incluir las plantillas, la validación de los datos de procedimiento contra el uso de una clase, o funciones vs clases para obtener los datos de la base de datos, etc.)

Como se puede ver, estoy tratando de entender cómo funcionan las cosas, y la mejor manera de hacer las cosas. Dicho esto, si usted tiene algún consejo, o cualquier consejos generales sobre el tema ... Por favor dejarlos ..

Gracias

Answer 1

aplicaciones Web y de N-capas que es interesante, sobre todo porque la noción de N-capas se ha ampliado con la adopción generalizada de JSON y AJAX o Flash y XMLRPC. Este tabla en Webopedia muestra una línea azul escalonada que expresa esta bien. Para resumir: su negocio, de acceso, y la lógica de presentación no sólo podrían existir en el servidor - pero en algunos casos, directamente en el navegador. La intención de N-capas, sin embargo, es separabilidad . Si es necesario cambiar a cabo su interfaz de usuario o su base de datos, o añadir otras interfaces de usuario, no debe afectar a su lógica de negocio. Y esto es lo que determinaría su API -. Anticipando el día en que su HTML y CSS se descartan para Flex, y MySQL está cambiado por Oracle

Este es requisitos determinados, y en algunas aplicaciones web que he usado, variaciones de N-capas se utilizan simultáneamente. Tomemos, por ejemplo LyrisHQ (un e-mail ASP). Tienen una aplicación web cliente. Recientemente, han mirado empujando su aplicación basada en Flash. Este es claramente el envío de una gran cantidad de datos de la derecha en el navegador, y es probable que haya un poco de lógica de negocios duplicado en la interfaz de usuario Flash. Ellos deben mantener ambas aplicaciones, sin embargo, ya que cualquiera de ellos es necesario para diferentes (y superpuestos) requisitos.

aplicaciones PHP más comunes no están considerando enviar tantos datos sin formato al navegador. Pero si lo fuera, esto sería informar que muy rápidamente la forma en que se desea diseñar sus APIs. Es muy probable que le gustaría que los controladores que podría hablar XMLRPC, REST, o SOAP ... además de una clase controladora interna similar que sus plantillas de presentación de PHP utilizan. Esto significaría estrictamente para una simple página web de inicio de sesión, que tendría una plantilla PHP para el formulario de acceso que hablaba a una clase LoginController. Una interfaz XML usaría asimismo la misma clase LoginController. Tal como lo haría suponer que estaría loco para escribir SQL en una petición Ajax ... que sería estrictamente evitando escribir consultas en sus plantillas de presentación.

capas de negocios pueden ser más o menos estricta, porque a menudo no hay nunca un requisito para cambiar de marca de base de datos back-end. En un estricto diseño de N-capas, cómo sus objetos de negocio que hablaría con su base de datos sería como si se pudiera cambiar de MySQL a MS SQL sin tener que reescribir la capa de negocio. A veces esto se hace mediante el modelado de objetos para cada tabla (Tabla Gateway), cada fila (registro activo), cada unión, o cada transacción. Aquí es donde algo así como DOP o PHP-ADO son útiles, pero no suficiente para el aislamiento completo. capas ORM / Persistencia en Java como Hibernate demuestran mejor este tipo de aislamiento, a menudo proporcionando un Objeto Query Language (NCO).

Yo, estoy actualmente llevando a cabo una transición back-end desde una aplicación PHP MySQL base a una MS-SQL uno. La aplicación se ha utilizado solamente nunca consultas SQL directas. Imagínese la elección de cómo tomar una serie de consultas en una clase y, o bien la abstracción de ellos, o subclases, y es de esperar que no altera la lógica de negocio. Como mínimo, tendrá que hacer toda su SQL llama indirecta. ( poste S.O. en PHP ORM .)

Y, por último, a su pregunta sobre programación orientada a objetos: utilizarlo cómo se debe de cumplir con sus requerimientos. Mi técnica personal es comenzar con la lógica de la derecha en una plantilla de presentación PHP durante unos minutos para llegar a rodar la pelota, muy pronto voy a refactorizarán que en una clase y una plantilla. Si tengo ideas comunes, que romper rutinas en clases compartidas, tratando de preservar el principio DNRY. (A SO publicar en eso aquí. POO no es un requisito fundamental para el diseño de N-capas. DNRY es muy importante para mantener su código mantenible, aunque. dediez plazos y el alcance de cambio de destruir una API. Refactorearlo hasta que se obtiene lo que necesita para seguir adelante. Apuesto programación orientada a objetos le ayudará a llegar allí.

Answer 2

Una vez leí algo diciendo que los modelos grandes (capa de negocio) se deben preferir los grandes controladores de acceso (capa).

También: Realmente depende del proyecto. En mis ojos no siempre tiene sentido utilizar programación orientada a objetos para todo (probablemente no todos estarán de acuerdo aquí), sobre todo en los lenguajes de scripting como PHP que muchas veces es más fácil hacer simplemente validadores como funciones ...

Answer 3

Yo definitivamente le aconsejaría que no tienen las llamadas bases de datos en la capa de presentación, que se aleja de su objetivo.

Existen diferentes enfoques para la arquitectura de varios niveles y tienen diferentes recomendaciones.

Zend Framework que los que he trabajado es por lo general de acuerdo con el modelo Fat variante de controlador / Delgado.

Si encontrar este artículo Notas sobre la elección de un marco PHP a ser bastante bueno en comparación (en este caso) CakePHP a Zend Framework.

La mayor diferencia en mi opionion es el enfoque de convenciones-sobre-configuración tomada por CakePHP que es muy diferente del enfoque de configuración en Zend Framework.

Mediante el uso de un marco, que tiene mucho sentido si la implementación de una arquitectura de varios niveles, su son de una manera forzada o por lo menos empujado en el uso de programación orientada a objetos, que no es una mala cosa.

Se podría, por supuesto, poner en práctica, por ejemplo una arquitectura de 3 capas con llamadas funcionales puros, pero no sería escala que bien basado en mi experiencia.

Para un sitio web el patrón MVC, que en realidad es bastante diferente debido a la forma en que se comunican los niveles, es una buena opción.

La diferencia entre un arco "normal" de 3 niveles y el patrón MVC es que la vista tiene acceso tanto al controlador y la capa de modelo, en tanto que la capa de presentación sólo tiene acceso a la capa de lógica de la 3-tier arch.

Answer 4

Estoy de acuerdo con lo que dijo Franz, especialmente sobre prefiriendo modelos más grandes sobre los controladores más grandes .. también puede utilizar una regla de oro para ayudar a distinguir donde el código debe ir: si tiene algo que ver con la estructura de la interfaz de usuario / flujo, puesto en el controlador; si es pura lógica de negocio, que va en el modelo ..

Voy a añadir que, como desarrollador Java que tenía mucha experiencia con puntales antes de poner a prueba las aguas PHP, me tomó un tiempo para entender cómo aplicar las ideas de MVC a un lenguaje de script .. Yo he encontrado que el uso de un sistema como CodeIgnitor ayudó mucho .. que proporciona el marco, al igual que Struts, y anima a los buenos patrones MVC ..

Answer 5

Mi mundo es el siguiente:

  

DB1 <- Model1 para proveer de acceso   funciones, integridad de datos, negocio   reglas para este conjunto de datos DB2 <- model2   para proporcionar funciones de acceso, los datos   integridad, reglas de negocio para esta   conjunto de datos

     

controlador: Controles de flujo de datos para   vistas, filtros / organiza los datos de   puntos de vista. Implementa reglas de negocio para   lo dado aplicación . conoce el   reglas de negocio entre los modelos.

     

Vistas: Nada más que las plantillas   que los datos de pantalla proporcionados por el   Controlador. Pasar todos los datos a la   controlador. No tiene conocimiento de   Model1 o Modelo2 o el negocio   lógica que los rige.

Answer 6

Yo recomiendo hacer una investigación sobre los patrones de diseño ya que es la pieza que falta en el puzzle. Hay una serie de libros específicas de PHP que cubren este tema (los de APulse son buenos), así como la 'biblia' de los patrones de diseño: "noreferrer Design Patterns: Elements of reutilizable de software orientado a objetos"

Answer 7

Vamos a esperar a la versión más estable de Doctrine2 .

Está siendo desarrollado con la filosofía objeto de dominio persistencia-ignorante. Será mucho más fácil desarrollar aplicaciones de varios niveles con la ayuda de este marco.