2012-08-24 17 views
8

Ya hay algunas publicaciones sobre la discusión de SO si esta arquitectura es una buena idea o una mala idea. Por muchas razones dentro de nuestra empresa, incluido el talento de programación existente, hemos decidido usar Java para el back-end y PHP para la interfaz. Nuestro objetivo es algo así como ...Usando Java como backend y PHP como interfaz

Java - Modelos/Controladores

PHP - Vistas

estamos trabajando en la construcción de un prototipo de la interacción entre GlassFish y Apache. Una cosa en la que todavía estamos trabajando es cuando un usuario visita http://domain.com/login.html e inicia sesión, ese inicio de sesión se enviará al controlador Glassfish que existe en algún lugar como /login.java. No podemos hacer eso, el problema es conseguir que la vista se represente en esa URL.

¿Alguien ha hecho esto con PHP o alguna otra tecnología?

+0

Como esa vieja canción [Lovin 'Spoonful] (http://www.metrolyrics.com/did-you-ever-have-to-make-up-your-mind-lyrics-lovin-spoonful.html) va : "¡tú deberías elegir uno y dejar el otro atrás!" ;) – paulsm4

Respuesta

2

Lamento mencionar esto, pero parece que sería mucho más sencillo seguir con uno de estos idiomas. Si está utilizando PHP para agregar más lógica a su vista, podría valer la pena echarle un vistazo al Velocity. Le permite acceder y crear variables, iterar a través de listas, usar condicionales, definir macros, hacer llamadas a métodos, etc. Esto parece que podría hacer las cosas mucho más limpias. Sin embargo, generalmente es una buena idea tratar de mantener la mayor cantidad de lógica posible fuera de sus plantillas.

Si desea utilizar PHP porque es lo que se requiere, le sugiero que consulte los servicios web para comunicarse. Eche un vistazo a la biblioteca de Googles GSON. Es una herramienta muy buena (en el lado de java) para asignar Objetos JSON a su modelo (y viceversa).

En su front-end, también vale la pena echarle un vistazo a Backbone. Es una herramienta que simplifica el simulacro de objetos modelo y les vincula eventos, o los agrega directamente a campos, etc.

+0

No use Velocity. Use algo como JSF, o incluso JSP. Velocity es un lenguaje de plantillas muy antiguo y también tiene muchas, muchas desventajas. JSF tiene un buen apoyo y puede hacer mucho por usted. – seangates

+0

¿De verdad? ¿Qué inconvenientes tiene la velocidad en comparación con el JSTL directo? Velocity realmente no requiere que modifique/escriba su código de ninguna manera específica. Simplemente pasa lo que sea que quieras y eso es todo. Puede llamar a métodos, establecer variables, declarar nuevos, etc. desde la plantilla. No es que debas poner toda esta lógica en una plantilla. Pero Velocity te permite. –

+0

A juzgar por la falta de soporte de los desarrolladores, en su mayoría. Le pregunté a muchos desarrolladores de Java qué plantillas usaron y solo una (en los últimos 3 años) se enteró de ello. – seangates

4

¿Ha considerado configurar un servidor de jabon/descanso en java y hable PHP con eso? Imagino que sería mucho más simple que lo que estás tratando de lograr.

+0

Lo hicimos en mi trabajo anterior y funcionó bien. El jabón es un dolor, pero está bien respaldado. Si quieres ser aventurero, puedes intentar una implementación de jsonrpc. – Jody

+0

- esa sería una de las implementaciones de comunicación IPC o socket. –

+2

Usamos una Java Rest API (JSON) como back-end y PHP como frontend. Fue una gran experiencia y también pudimos usar el mismo backend para plataformas móviles. – Gonzalo

1

He tenido experiencia de primera mano en dos empresas que utilizan el servicio Java capa y PHP Cliente pila de tecnología de capa, aunque no se utilizó exclusivamente. Para separar claramente las capas, se creó una API JSON REST bien definida, de modo que cada capa tuviera un contrato al que podría codificarse.

capa The Java utiliza SpringMVC en-entre la capa de persistencia para generar vistas JSON con bien definido rutas (estructura de la URL es decir) para que la capa de PHP a GET/PUT/POST/DELETE recursos.

En relación con el número de inicio de sesión específicamente, en realidad había dos servicios de Java, uno específicamente para iniciar sesión/cerrar sesión y el otro para el backend regular.

Al visitar /login que supongo que sería un archivo .php. El envío del inicio de sesión <form> al servicio "Iniciar sesión" dio como resultado la adición de una cookie de sesión, pero también una cookie "ID de usuario" encriptada. La cookie encriptada podría usarse para proteger el acceso a la capa de servicio de Java para el producto. Cada solicitud de REST de PHP a Java tendría acceso a la cookie, y la capa de Java podría descifrar la "ID de usuario" y responder a la llamada de PHP REST si fuera válida.La capa de Java tendría acceso a la identificación de usuario real para devolver datos específicos del usuario de la tienda persistente.

+0

Si bien la mayoría del servicio fue reparador, parece que el inicio de sesión no era, y además, el inicio de sesión dependía de la interfaz PHP, por lo que creo que perdió un poco * la separación de las preocupaciones * un poco. – WhyNotHugo

+0

Si tiene dos capas heterogéneas, tiene sentido usar un servicio web. Si está utilizando servicios web, tiene sentido usar REST/JSON (en lugar de WS/SOAP). ... PERO ... sería * MEJOR * si no se acumulara innecesariamente en varias capas diferentes en el * PRIMER lugar *! En mi humilde opinión ... – paulsm4

+0

El inicio de sesión no dependía de PHP. Era un servicio Java externo que solo se preocupaba por el inicio de sesión. La forma en que un producto lo llamaba dependía de ellos, ya sea de PHP o Java. Una vez que se lograba un inicio de sesión exitoso, cada uno de los _product_ debía proteger sus recursos mediante el uso de la cookie. Tenga en cuenta que esto no era ** mi ** arquitectura, solo estoy detallando información sobre una pila de tecnología con la que trabajé. – andyb