javascript - mvc - Creación de una aplicación JS de varias páginas con acoplamiento flexible utilizando Core(Mediator)/Sandbox(Fachada)/Patrón de módulo: ¿consejos?

mvc javascript ejemplo

Question

Estoy construyendo una aplicación javascript de varias páginas. He leído mucho sobre los patrones de diseño y la creación de aplicaciones utilizando un enfoque de núcleo / fachada / módulo con acoplamiento suelto (publicación / suscripción a eventos).

Tengo un sistema bastante bueno que minimiza y combina todos mis archivos de módulo y dependencias relacionadas en un solo archivo javascript externo en la implementación. Minimizar las solicitudes HTTP adicionales para mi aplicación es un objetivo de diseño, por lo tanto, no estoy demasiado interesado en AMD (definición de módulo asíncrono).

Estoy usando las pautas delineadas en la presentación de Nicholas Zakas, Arquitectura de aplicación de JavaScript escalable.

http://www.youtube.com/watch?v=vXjVFPosQHw

&&

Patrones de Addy Osmani para la arquitectura de aplicaciones de JavaScript a gran escala http://addyosmani.com/largescalejavascript/

&&

Este tutorial premium, por Andrew Burgess de Nettuts, Escribiendo JavaScript modular http://marketplace.tutsplus.com/item/writing-modular-javascript/128103/?ref=addyosmani&ref=addyosmani&clickthrough_id=90060087&redirect_back=true

Mi pregunta es sobre cómo administrar las diferentes páginas de esta aplicación y sus módulos asociados. También estoy usando la clase Router de Backbonejs con la biblioteca History.js de ballupton para manipular la API de estado / historial de HTML5 y cargar dinámicamente páginas sin una actualización mientras mantengo la compatibilidad con versiones anteriores de navegadores antiguos que no admiten la API de estado HTML. Todas mis páginas comparten una base de código común (solo archivo js minificado y comprimido).

Aquí hay un resumen de la estructura que estoy pensando usar en mi aplicación:

Es esencialmente un enfoque híbrido. La mitad superior consiste en un patrón de núcleo / fachada / módulo con módulos discretos que no interactúan directamente entre sí y publican / suscriben notificaciones a través de la fachada.

La mitad inferior consta de mi estructura de aplicación propuesta, que notifica a un "controlador principal" cuando el estado / url cambia, el controlador principal realiza cualquier operación global (como inicializar el encabezado y el menú de la barra lateral de mi interfaz de usuario si aún no se ha inicializado) y le indica al sub-control relevante que ejecute el método init () (además de llamar a destroy (); en cualquier controlador que se haya cargado previamente). Cada subcontrolador (se correlaciona con ej .: página de inicio, página de calendario, página de reservas, etc.) selecciona los módulos del grupo de módulos disponibles y los inicializa.

¿Es este un buen enfoque o estoy en un mal camino? Puedo ver que los módulos aún son independientes entre sí, lo que es bueno para la escalabilidad.

También he considerado simplemente tratar al Router & Controllers como módulos discretos y hacer que publiquen / suscriban al Core, y cada controlador de alguna manera inicializa los módulos necesarios para su página.

Answer 1

Creo que es un buen enfoque. He estado desarrollando algo similar en 2 enormes aplicaciones web comerciales (menos la red troncal, y con un administrador de historial personalizado) y funciona muy bien. Tampoco estoy usando AMD y todas las interacciones son manejadas por pub / sub. Una de mis mejores inspiraciones (que estoy seguro de que ya conoces) es: https://github.com/aurajs/aura

Answer 2

Una cosa que hicimos para mantener el historial funcionando sin problemas fue cambiar primero la URL. Al cambiar la URL, se activaría un evento, el enrutador analizaría la URL y luego averiguaría qué hacer. Este evento también se activaría automáticamente al cargar la página. Si hiciera clic en un enlace, simplemente cambiaría la URL, que es bastante simple y desacopla completamente los enlaces / botones de la lógica de la aplicación. Esto pareció funcionar bien para nuestra aplicación. Utilizamos JQM, pero eliminamos la mayoría de sus enrutadores, ya que leímos la mayoría de nuestras instrucciones de algún archivo XML y no teníamos un montón de páginas HTML para cargar en el área de la ventana principal.

Muchas veces he visto que las aplicaciones troncales utilizan el enrutador como el núcleo / mediador. Esta es una buena idea. Simplemente puede escuchar los eventos de cambio de la URL y luego cambiar la página adecuadamente. Este mediador probablemente debería ser un singleton, aunque los singletons son más difíciles de probar por unidad.

Lo que no necesariamente estaba de acuerdo con Backbone era su definición de "vistas". El tipo de vista parece una acción en un controlador (bien desde algunas perspectivas). Agregamos un nivel más de separación en nuestra aplicación en ese punto. Nuestras vistas hicieron solicitudes ajax a archivos de plantilla que se rellenaron con algunos JSON y handlebars.js. Yo diría que su encabezado / barra lateral debería ser simplemente plantillas. Si necesita actualizarlos, vea cómo podría hacerlo de manera extremadamente simple; de ​​lo contrario, está pensando en crear 4 nuevos módulos: colección para una lista, modelo para cada elemento, vista de colección y vista de modelo. Combinaría las plantillas más estrechamente con una vista de nivel superior hasta que deban desglosarse más (por ejemplo, algunas "Aplicaciones / Vista principal").

Tener esta capa de plantilla te permite hacer cambios superficiales sin recompilar también, lo cual es bueno. Cada vez que puedes poner cosas en "meta" es una victoria (bueno, a menos que requieras que leas XML (ha)) Como beneficio adicional, también puede almacenar en caché la plantilla por separado (o guardarla en la memoria caché por separado).

Sin embargo, su arquitectura parece estar bien y es un enfoque válido para su problema. Un consejo que daría es no sobre diseñar por adelantado. Lo mejor es iterar. Tendrá que refactorizar. Es imposible prever qué es lo que haría que su aplicación fluya con más facilidad con 3 a 6 meses de anticipación.

Actualización del 18 de diciembre de 2013

Hoy en día estamos usando marionetas y más trucos osmani adicionales. Además de los elementos anteriores, estamos utilizando el formato alternativo de AMD:

define(function(require) {
    var myTemplate = require(''hb!mytemplate.handlebars''),
        view = require(''myview'');
    ...
});

También estamos utilizando la clase de aplicación marionette en combinación con wreqr que proporciona una capa de solicitud / respuesta. Esto nos permite configurar los objetos de la aplicación limpiamente. También nos permite definir clases sin indicar explícitamente el nombre de la clase. Esta es una forma bastante buena de sandbox. P.EJ:

this.app.setHandler(''CanvasClass'', function() {
    return RaphaelCanvasView;
});

// elsewhere

this.app.request(''CanvasClass'').text(''123'', {x:1, y:2});

Todo esto parece funcionar bastante bien.

También debe comprobar aura js y componentes web. Nuestro tipo de estructura de directorio imita / anticipa esos conceptos sin invertir aún en ellos.