La arquitectura de marco más flexible para el desarrollo web?

Question

Obviamente, no existe una única solución que satisfaga las necesidades de todos; una arquitectura siempre es una compensación. Quiero crear un marco, originalmente dirigido a RAD de juegos web. El idioma de destino es PHP, aunque la arquitectura debe ser ampliamente aplicable.

Las metas que tengo en mente para este marco son: flexibilidad en la forma de lograr el resultado; máxima comodidad para los desarrolladores; módulos de conexión como bloques LEGO ®; muchos tipos de entrada, muchos tipos de salida, un formato para el procesamiento.

Las metas que no son una prioridad son la velocidad, el uso empresarial y la obtención de dinero. Se supone que es un proyecto de código abierto.

La piedra angular de este diseño es que todo el contenido, antes de la transformación, se procesa en XML (idea basada en el sistema EAI con el que he trabajado, eGate). La capa de abstracción de datos (espero que algún ORM inteligente) no sea importante ahora. La salida se generará utilizando XSLT o cualquier otro módulo personalizado, para prácticamente cualquier cliente: HTML para navegadores antiguos, XHTML/HTML5 para navegadores modernos, HTML simple para clientes móviles, XML para AJAX/XMLRPC, etc.

Principales motivos para el uso de XML son:

• es un conocido
• herramientas estándar existentes, como XPath, SimpleXML y DOM para navegar y modificar el contenido
• XSLT que proporciona una forma poderosa y unificada para transformar el código en cualquier etiqueta sopa
• Encuentro el marcado XML muy fácilmente legible, por lo tanto, no creo que las ventajas de JSON o YAML marquen la diferencia aquí
• El contenido se puede apilar fácilmente, y el orden del contenido en realidad no importa siempre que se haya transformado correctamente con XSLT

El proceso de generación de la página consistiría en estas fases:

1. Pre-procesamiento: módulos de inicialización, el procesamiento de datos de GPC, la aplicación de [XML] plantillas predeterminadas
2. de procesamiento/generación: parte principal de la lógica de negocio, generando el XML inflado con datos máximos (aunque afortunadamente optimizado) no generar balast)
3. Procesamiento: alguna lógica comercial adicional, p. reduciendo parte del marcado, preparándose para la transformación, informes, estadísticas, etc.
4. Post-procesamiento: análisis XML a través del motor de transformación (probablemente solo XSLT), salida.

El contenido se generaría con una gran cantidad de meta-datos (por ejemplo, las etiquetas, los permisos, la importancia, la necesidad, el tipo de salida dirigida), que se desnudó durante el post-procesamiento.

Entonces, mi pregunta es: a excepción de la velocidad, ¿cuál es la caída de esta solución? ¿Dónde podría salir mal durante el desarrollo/mantenimiento del marco y sus aplicaciones? ¿Cuáles son los inconvenientes de esta arquitectura?

Answer 1

XSLT puede ser voluminoso de administrar, y básicamente agrega un lenguaje de programación adicional en el que los desarrolladores tendrían que trabajar (al menos si entiendo su descripción correctamente). Mi experiencia ha sido que relativamente pocas personas lo saben, y aún menos pueden hacerlo hacer lo que quieren.

Answer 2

He trabajado en algunos juegos web en el pasado y, para ser honesto, ninguno de ellos ha necesitado algo tan complejo y difícil de manejar.

Answer 3

Creo que está buscando una solución muy complicada. Es un gran esfuerzo simplemente diseñar y construir los esquemas que usará. Si está en un proyecto que involucra a más de 5-6 personas en total, es probable que necesite un esfuerzo de diseño de esquema organizado. Creo que este es un punto que conoces.

Me pregunto y, posiblemente, tema de la selección de PHP en el front end. También creo que estás decidiendo sobre XML en un gran sentido por error.

Aquí es lo que hago:

1. construir una capa de servicio utilizando Grails.org
2. Mantenga todos los recursos que pueden ser de descanso en reposo
3. Usar el plugin X-fuego en Grails para construir cualquier servicio SOAP que necesite construirse
4. Aproveche la funcionalidad GORM y RAD de Grails para reducir el tiempo de desarrollo.
5. Construya clientes en lenguaje X o Y o plataforma para consumir estos servicios.

Definitivamente quisiera la velocidad de Java puro haciendo toda mi traducción/procesamiento XML. Si tiene documentos grandes, tomará bastante tiempo procesarlos.

Entiende las fuerzas de su entorno mejor que nadie, pero le advierto que haga lo más simple que funcione primero y no sobre arquitecto.

Answer 4

No estoy seguro de qué "marco flexible" sugerirle tampoco. Todo depende de lo que te sientas cómodo y de tu gusto personal.

Una cosa que sí sé es que, al principio, lo atractivo que puede parecer es mantenerse alejado de XSLT. Hacer cosas tipo Hello World y ejemplos simples con XSLT es bastante directo. Sin embargo, los proyectos más complejos se vuelven completamente inmanejables (sin mencionar que no se pueden leer) con XSLT. Mi experiencia es que pone una presión masiva en el proyecto.

Answer 5

Lo que describes podría implementarse usando tox. Utiliza una arquitectura híbrida MVC-ARS. El obstáculo que veo es el punto de costo tox se presenta debido a su dependencia de Oracle. Por supuesto, dado que es de código abierto, puede convert it to Postgresql.