¿Enfoques “arquitectónicos” alternativos al código de cliente javaScript?

StackOverflow https://stackoverflow.com/questions/32540

Pregunta

¿Cómo está organizado su código javaScript?¿Sigue patrones como MVC o algo más?

He estado trabajando en un proyecto paralelo desde hace algún tiempo y cuanto más avanzo, más mi página web se convierte en una aplicación con todas las funciones.Ahora mismo me quedo con jQuery, sin embargo, la lógica de la página está creciendo hasta un punto en el que se necesita cierta organización, o me atrevo a decir, "arquitectura".Mi primer enfoque es "MVC-ish":

  • El 'modelo' es un árbol JSON que se amplía con ayudas
  • La vista son las clases DOM plus que la modifican.
  • El controlador es el objeto donde conecto el manejo de eventos y inicio la manipulación de la vista o del modelo.

Sin embargo, estoy muy interesado en cómo otras personas han creado aplicaciones JavaScript más importantes.No estoy interesado en GWT ni en otros enfoques orientados al servidor...justo en el enfoque de "javaScript + <servicio web genérico-y cosa aquí>"

Nota:Antes dije que JavaScript "no es realmente OO, no es realmente funcional".Creo que esto distrajo a todos.Digámoslo de esta manera, debido a que javaScript es único en muchos sentidos y vengo de una experiencia fuertemente tipada, no quiero forzar paradigmas que conozco pero que fueron desarrollados en lenguajes muy diferentes.

¿Fue útil?

Solución

..pero Javascript tiene muchas facetas que son OOO.

Considera esto:

var Vehicle = jQuery.Class.create({ 
   init: function(name) { this.name = name; } 
});

var Car = Vehicle.extend({ 
   fillGas: function(){ 
      this.gas = 100; 
   } 
});

He usado esta técnica para crear clases de JavaScript a nivel de página que tienen su propio estado, esto ayuda a mantenerlo contenido (y a menudo identifico áreas que puedo reutilizar y poner en otras clases).

Esto también es especialmente útil cuando tiene componentes/controles de servidor que tienen su propio script para ejecutar, pero cuando puede tener varias instancias en la misma página.Esto mantiene al Estado separado.

Otros consejos

JavaScriptMVC es una excelente opción para organizar y desarrollar una aplicación JS a gran escala.

El diseño arquitectónico muy bien pensado.Hay 4 cosas que alguna vez harás con JavaScript:

  1. Responder a un evento
  2. Solicitar Datos / Manipular Servicios (Ajax)
  3. Agregue información específica del dominio a la respuesta ajax.
  4. Actualizar el DOM

JMVC los divide en el patrón Modelo, Vista, Controlador.

La primera ventaja, y probablemente la más importante, es el controlador.Los controladores utilizan la delegación de eventos, por lo que en lugar de adjuntar eventos, simplemente crea reglas para su página.También utilizan el nombre del Controlador para limitar el alcance de lo que trabaja el controlador.Esto hace que su código sea determinista, lo que significa que si ve que ocurre un evento en un elemento '#todos', sabrá que tiene que haber un controlador de todos.

$.Controller.extend('TodosController',{
   'click' : function(el, ev){ ... },
   '.delete mouseover': function(el, ev){ ...}
   '.drag draginit' : function(el, ev, drag){ ...}
})

Luego viene el modelo.JMVC proporciona una clase potente y un modelo básico que le permite organizar rápidamente la funcionalidad Ajax (n.° 2) y envolver los datos con una funcionalidad específica del dominio (n.° 3).Cuando esté completo, puede usar modelos de su controlador como:

Todo.findAll({después:nueva Fecha()}, myCallbackFunction);

Finalmente, una vez que todos regresen, debes mostrarlos (#4).Aquí es donde usas la vista de JMVC. 

'.show click' : function(el, ev){ 
   Todo.findAll({after: new Date()}, this.callback('list'));
},
list : function(todos){
   $('#todos').html( this.view(todos));
}

En 'vistas/todos/list.ejs'

<% for(var i =0; i < this.length; i++){ %>
   <label><%= this[i].description %></label>
<%}%>

JMVC proporciona mucho más que arquitectura.Le ayuda en cualquier parte del ciclo de desarrollo con:

  • Generadores de código
  • Pruebas integradas de navegador, Selenium y Rhino
  • Documentación
  • Compresión de guiones
  • Error al reportar

MochiKit es genial, y fue mi primer amor, por así decirlo, en lo que respecta a las bibliotecas js.Pero descubrí que, si bien MochiKit tiene una sintaxis muy expresiva, no me resultaba tan cómodo como lo eran Prototype/Scriptaculous o jQuery.

Creo que si conoces Python o te gusta, entonces MochiKit es una buena herramienta para ti.

Gracias a todos amablemente por sus respuestas.Después de un tiempo, me gustaría publicar lo que he aprendido hasta ahora.

Hasta ahora, veo una diferencia muy grande en el enfoque que usa algo como ext, y otros como Interfaz de usuario jQuery, Scriptaculous, MochiKit, etc.

Con Ext, el HTML es solo un marcador de posición: la interfaz de usuario va aquí.A partir de entonces, todo se describe en JavaScript.La interacción DOM se minimiza bajo otra capa API (quizás más fuerte).

Con los otros kits, comienzo haciendo un poco de diseño HTML y luego extendiendo el DOM directamente con efectos llamativos, o simplemente reemplazando la entrada del formulario aquí, una adición allá.

Las principales diferencias comienzan a ocurrir cuando necesito ocuparme del manejo de eventos, etc.Como los módulos necesitan "hablar" entre sí, me encuentro en la necesidad de alejarme del DOM, abstrayéndolo en partes.

Observo que muchas de estas bibliotecas también incluyen algunas técnicas de modularización interesantes.Se aporta una descripción muy clara en el sitio web de Ext, que incluye una forma elegante de "proteger" su código con módulos.

Un nuevo jugador que he evaluado completamente es núcleo de brotes.Parece un enfoque Ext, donde el DOM está oculto y principalmente desea lidiar con la API del proyecto.

Tristan, encontrarás que cuando intentas diseñar JavaScript como una aplicación MVC, tiende a quedarte corto en un área: el modelo.El área más difícil de tratar es el modelo porque los datos no persisten en toda la aplicación y, por naturaleza, los modelos parecen cambiar en el lado del cliente de manera bastante consistente.Podría estandarizar la forma en que pasa y recibe datos del servidor, pero en ese momento el modelo no pertenece realmente a JavaScript, sino a su aplicación del lado del servidor.

Hace un tiempo vi un intento en el que alguien creó un marco para modelar datos en JavaScript, muy parecido a la forma en que SQLite pertenece a la aplicación.Era como Model.select( "Producto") y Model.update( "Producto", "Algunos datos...").Básicamente era una notación de objetos que contenía una gran cantidad de datos para administrar el estado de la página actual.Sin embargo, en el momento en que actualiza, todos esos datos se pierden.Probablemente me equivoque en la sintaxis, pero entiendes el punto.

Si está utilizando jQuery, entonces el enfoque de Ben es realmente el mejor.Extienda el objeto jQuery con sus funciones y propiedades, y luego compartimente sus "controladores".Normalmente hago esto colocándolos en archivos fuente separados y cargándolos sección por sección.Por ejemplo, si fuera un sitio de comercio electrónico, podría tener un archivo JS lleno de controladores que manejan la funcionalidad del proceso de pago.Esto tiende a mantener las cosas livianas y fáciles de manejar.

Sólo una rápida aclaración.

Es perfectamente factible escribir aplicaciones GWT que no estén orientadas al servidor.Supongo que por Orientado al servidor te refieres a GWT RPC que necesita un back-end basado en Java.

He escrito aplicaciones GWT que son muy "MVC-ish" sólo en el lado del cliente.

  • El modelo fue un gráfico de objetos.Aunque codifica en Java, en tiempo de ejecución los objetos están en javascript sin necesidad de ninguna JVM ni en el lado del cliente ni en el del servidor.GWT también admite JSON con soporte completo de análisis y manipulación.Puede conectarse a servicios web JSON fácilmente, consulte 2 para ver un ejemplo de mashup JSON.
  • La vista estaba compuesta por widgets GWT estándar (más algunos de nuestros propios widgets compuestos)
  • La capa del controlador se separó claramente de la Vista mediante el patrón Observador.

Si su experiencia "fuertemente tipada" es con Java o un lenguaje similar, creo que debería considerar seriamente GWT para proyectos grandes.Para proyectos pequeños normalmente prefiero jQuery.Próximo Consulta GWT que funciona con GWT 1.5 puede cambiar eso, aunque no en un futuro próximo debido a la abundancia de complementos para jQuery.

No estoy 100% seguro de lo que quieres decir aquí, pero diré que después de usar ASP.NET durante los últimos 6 años, mis páginas web ahora funcionan principalmente con JavaScript una vez que el servidor realiza la representación básica de la página.Utilizo JSON para todo (lo he usado durante aproximadamente 3 años) y uso MochiKit para mis necesidades del lado del cliente.

Por cierto, JavaScript es OO, pero como utiliza herencia prototípica, la gente no le da crédito de esa manera.También diría que es funcional, todo depende de cómo lo escribas.Si está realmente interesado en estilos de programación funcional, consulte MochiKit - puede que te guste;se inclina bastante hacia el lado de programación funcional de JavaScript.

Licenciado bajo: CC-BY-SA con atribución
No afiliado a StackOverflow
scroll top