design-patterns - most - software architecture patterns pdf
Arquitectura de plugin en aplicaciones web(¿Ejemplos o fragmentos de código?) (4)
Estoy tratando de aprender a desarrollar una aplicación web (preferiblemente NodeJS / MongoDB, aunque utilicé PHP y Python antes) que es altamente ampliable y personalizable a través de complementos para habilitar la funcionalidad deshabilitada.
Una posible opción es usar Wordpress con ganchos para complementos y widgets para enganchar, sin embargo, carece de la separación adecuada de la vista y el código lógico. Eso sigue siendo una opción para aprender. ¿Hay más opciones?
¿Tienes algún fragmento de código o aplicación de ejemplo de la que pueda aprender? El lenguaje o el marco no es tan importante, probablemente podría entender el concepto que hay detrás
No tenemos una arquitectura de complementos como tal, pero explicaré cómo mantenemos nuestro código de cliente vagamente acoplado, y tal vez le brinde algunas ideas.
Estamos usando asp.net. Entregamos una página main.aspx que primero incluye un archivo javascript mediador. Define un objeto global, llámalo mediador, que es el único objeto global que definimos.
El mediador expone una interfaz simple con mensajes de publicación y suscripción:
mediator.subscribe(messageName, callback);
mediator.publish(messageName);
Después del archivo mediator.js, la página principal incluye una serie de otros archivos javaScript, cada uno de los cuales consiste en una función inmediata que registra su funcionalidad con el mediador. Se puede encontrar más información sobre este patrón here , o ver una pregunta anterior here .
Podría seguir un enfoque similar: defina un único objeto global (por ejemplo, pluginFramework) que ofrezca una interfaz para que los complementos registren su funcionalidad. Cuando construya la página html para entregarla al cliente, primero incluya el archivo pluginFramework y luego incluya dinámicamente los archivos de complemento de JavaScript deseados, que podrían depender del usuario o del dispositivo (por ejemplo, ¿diferentes complementos si el dispositivo está habilitado para tocarlo?). Estos archivos de complemento agregarían su funcionalidad al pluginFramework con una función inmediata.
Aquí hay un ejemplo de cómo permitir que los complementos añadan funcionalidad a un menú en la interfaz de usuario:
pluginFramework.js:
var pluginFramework = (function() {
var menuItems = [];
function addMenuItemPrivate(itemName, callback) {
// e.g. add itemName and callback to menuItems
}
return {
addMenuItem: addMenuItemPrivate;
}
})());
photoPlugin.js:
(function() {
function addPhoto() {
//...
}
pluginFramework.addMenuItem(''add photo'', addPhoto)
})());
Espero que esto haya sido de alguna manera útil.
Si usted mismo está haciendo la personalización del cliente, Django parece ideal para esto. Cree su aplicación principal que maneje todas las funciones básicas que le gustaría. Luego, para cada cosa separada lógicamente que necesita hacer / crear una nueva aplicación que puede conectar a la principal, simplemente agregue esa aplicación a sus aplicaciones instaladas en la configuración.
Esto se encarga de la creación de aspectos (solo plop en una nueva plantilla base_site.html, todos los demás se heredan de ella), compatibilidad con múltiples bases de datos, complementos, y le brinda la capacidad de desarrollar e implementar nuevos complementos / características con bastante rapidez.
Consulte merengue o pinax para obtener ejemplos más genéricos de lo que podría ser su sistema interno.
Su comentario sugiere que lo que está construyendo es una arquitectura de varios inquilinos .
Este es un requisito complejo, y uno que generalmente es bastante difícil de adaptar; Depende en gran medida de donde estés empezando.
En primer lugar, debes tener una aplicación web con un factor decente en primer lugar; Si está utilizando un marco MVC, tiene un punto de partida.
En segundo lugar, debe decidir dónde va a admitir las extensiones; Por ejemplo, ¿puede un cliente tener un aspecto completamente separado para su UI? Si es así, necesita un marco de piel. ¿Pueden los clientes cambiar todo o simplemente conectar diferentes componentes en puntos clave (por ejemplo, un proveedor de pago personalizado o un esquema de autenticación personalizado)? Es mucho más fácil admitir un conjunto limitado de puntos de extensión que diseñar un marco que permita que cualquier cosa se extienda.
Luego, tu estrategia de datos; hay un buen artículo sobre tenencia múltiple en MSDN ; está orientado a bases de datos relacionales, pero proporciona ideas que puede aplicar a Mongo.
Finalmente, debe crear una arquitectura de componentes que admita los puntos de extensión que necesita. Como se trata de una aplicación web, debe poder modificar el Modelo, la Vista, el Controlador y la persistencia; la mejor solución es utilizar la forma en que su marco MVC quiere trabajar y poner la lógica "para el arrendatario x, hacer y; para el arrendatario z, hacer w" en la capa del controlador. Juega con esto, haz que funcione para algunos de los casos que necesitas, y luego resuelve qué está mal al respecto y arréglalo.
Una buena arquitectura de complementos es difícil de lograr desde cero, pero ofrece sus propias recompensas. Hace que el software sea flexible y fácil de mantener localizando la complejidad. La habilidad más importante que requiere es la capacidad de escribir código débilmente acoplado . Esto exige una comprensión muy firme del polimorfismo, la Ley de Demeter y el principio relacionado con Hollywood .
Recomiendo que inicialmente se familiarice con ellos, luego los siguientes patrones de diseño, lo que reducirá significativamente la dificultad:
- Patrón de comando : le da a los módulos de complementos un punto de entrada consistente, lo que les permite intercambiarlos fácilmente, un ejemplo basado en web de IBM .
- Memento : captura, mantiene y externaliza el estado sin violar la encapsulación, permite que los complementos sean configurados por el contenedor.
- Devolver llamada : permite que los módulos de complementos accedan a ''servicios'' desde el contenedor / entorno.
- Inyección de dependencia : una forma de aflojar el acoplamiento de los módulos de complemento de su entorno.
- Patrón abstracto de fábrica : instalar e instanciar el complemento en el entorno.
- Patrón de generador : requerido para cualquier arquitectura de complemento no trivial donde los módulos de complemento dependen el uno del otro.
Una vez que los tenga, estudie algunas de las implementaciones y arquitecturas de Plugin Framework existentes para ver cómo se han utilizado. Apache tiene varios en Struts , conjuntos de servidores personalizados Geronimo y recursos JNDI de Tomcat ; También el marco de plugin de Eclipse .