aplicaciones de varios niveles con PHP?

Question

Yo soy relativamente nuevo en PHP, pero experimentó programador de Java en entornos empresariales complejos con arquitectura SOA y aplicaciones multicapa. Allí, nos gustaría normalmente implementar aplicaciones de negocio con la lógica de negocio en el nivel medio.

Estoy programando un sistema de moneda alternativa, que sea de fácil despliegue y personalizable por los individuos y las comunidades; que será de código abierto. Es por eso que PHP / MySQL parece ser la mejor opción para mí.

Los usuarios tienen cuentas, y consiguen un equilibrio. También, los precios sistema calcula en función de los servicios totales entregados y activos totales disponibles.

Esto significa, por una compra de una serie de cálculos ocurren; el equilibrio y los totales se actualizan; Estas cifras se derivan, algo que normalmente no se ponen en una base de datos.

Sin embargo, he recurrido a poner disparadores y procedimientos almacenados en la base de datos, de modo que en el código php ninguna de estas actualizaciones se realizan.

¿Qué piensa la gente? Es que un enfoque bien? Mi experiencia me sugiere que esta no es la mejor solución, y me lleva a poner en práctica un nivel medio. Sin embargo, yo no sabría ni cómo hacerlo. Por otro lado, lo que tengo hasta ahora con procsos tienda me parece el más adecuado.

espero que hice mi pregunta clara. Todos los comentarios apreciados. Puede que no haya una solución "perfecta".

Answer 1

Como es la tendencia en estos días, alejándose de la base de datos es generalmente una buena cosa. Usted consigue el control versión más fácil y usted tiene que trabajar en un solo idioma. Más que eso, siento que los procedimientos almacenados son una forma difícil de seguir. Por otro lado, si te gusta eso y se siente cómodo con los SP en MySQL, no es malo, pero mi sentimiento siempre ha sido que son más difíciles de depurar y más difícil de manejar.

En el tema desencadenantes, no estoy seguro de si eso es necesario para su aplicación. Desde los acontecimientos que desencadenan los cálculos son invocados por el usuario, esas cosas pueden suceder en PHP, incluso si el usuario es redirigido a una "espera" página u otra página en el ínterin. Obviamente, los verdaderos disparadores sólo se puede hacer en el nivel base de datos, pero se puede utilizar un hilo de utilidad que se ejecuta un script PHP cada X segundos ... Evitar a toda costa y tratar de conseguir que el evento de disparo desde el lado del usuario.

Todo esto, dijo, quería conectar mi solución preferida para la capa de acceso a datos en PHP: Doctrina . No es perfecto, pero PHP siendo lo que es, es lo suficientemente bueno. Hace la mayor parte de lo que quiere, y te mantiene trabajando con objetos en lugar de procedimientos de base de datos y así sucesivamente.

En cuanto a su título, de múltiples niveles son, en PHP, totalmente factible, pero hay que hacerlas y respetarlos. código PHP puede llamar a otro código PHP, y es ahora (5.2 +) OO muy bien y todo eso. Aseguraos de pasar por alto el hecho de que una gran cantidad de código PHP verá en todo es una mierda total y ni siquiera se usan métodos, vamos niveles solos, y el modelado OO decente. Todo esto es posible si usted quiere hacerlo, incluyendo hacer su propia (o usar una ya existente) solución MVC.

Answer 2

Un problema con empujando un montón de características para el nivel de base de datos, en lugar de una capa de abstracción de datos, es que se bloquea el acceso al conjunto de características de los DBMS. software de código abierto se escribe a menudo de modo que pueda ser utilizado con diferentes DBs (ciertamente no siempre). Es posible que en el futuro tendrá que hacer que sea fácil de portar a postgres o algunos otros DBMS. El uso de un montón de características específicas de MySQL ahora hará que más difícil.

Answer 3

No hay absolutamente nada malo en usar disparadores y procedimientos almacenados y otras características que son proporcionados por el servidor de base de datos. Funciona y funciona bien, está utilizando todo el potencial de la base de datos, en lugar de simplemente relegándolo a ser un almacén de datos simplista.

Sin embargo, estoy seguro de que para todos los desarrolladores de aquí que esté de acuerdo con usted (y yo), hay al menos tantos que piensan exactamente lo contrario y han tenido buenas experiencias con hacer eso.

Answer 4

Gracias chicos.

Yo estaba usando disparadores db porque pensé que podría ser más fácil de integridad de las transacciones de control así. Como usted puede darse cuenta, soy un desarrollador que también está tratando de conseguir el agarre del conocimiento db.

Ahora, veo que es la solución para difundir el código php en múltiples niveles, no sólo lógicamente, sino también físicamente mediante el despliegue en servidores diferentes.

Sin embargo, en esta etapa de desarrollo, creo que me quedo con mi solución disparadores / SP, como que no se siente ser que mal. La distribución en múltiples capas me requeriría rediseñar mi aplicación consistente.

Además, el pensamiento de código abierto, si a alguien le gusta el sistema monetario alternativo, puede ser que sea más fácil para las personas a disposición de cambio sólo por sus necesidades, mientras que yo no tendría que preocuparse de que los cálculos ponen mal si la gente se toca el código php.

Por otro lado, por supuesto, estoy de acuerdo que las cosas db podría ser muy difíciles de depurar.

El DB init guiones están en control de origen, al igual que los archivos php:)

Gracias de nuevo