Enfoques "arquitectónicos" alternativos al código del cliente javaScript?

Question

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

He estado trabajando en un proyecto paralelo desde hace un tiempo, y cuanto más obtengo, más se ha convertido mi página web en una aplicación con todas las características. En este momento, me estoy quedando con jQuery, sin embargo, la lógica en la página está creciendo a un punto donde se necesita alguna organización, o me atrevo a decir que, "arquitectura". Mi primer acercamiento es "MVC-ish":

• El 'modelo' es un árbol JSON que consigue ampliar con ayudantes
• La vista es el DOM más clases que retocarlo
• El controlador es el objeto donde conecto la gestión de eventos y la vista o la manipulación del modelo

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

Nota: anteriormente dije javaScript "no es realmente OO , no realmente funcional ". Esto, creo, distrajo a todos. Digámoslo de esta manera, porque javaScript es único en muchos sentidos, y provengo de un fondo fuertemente tipado, no quiero forzar paradigmas que conozco, pero fueron desarrollados en idiomas muy diferentes.

Answer 1

..pero Javascript tiene muchas facetas que son OO.

Considere esto:

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

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

He utilizado esta técnica para crear clases de JavaScript de nivel de página que tienen su propio estado, esto ayuda a mantener contenía (y yo a menudo a identificar las áreas que puedo volver a utilizar 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 el estado separado.

Answer 2

No es 100% seguro de lo que quiere decir aquí, pero he de decir que después de hacer ASP.NET para los últimos 6 años, mis páginas web están ahora en su mayoría impulsados ​​por JavaScript una vez que la prestación página básica se realiza por el servidor. Utilizo JSON para todo (he estado alrededor de 3 años) y uso MochiKit para mis necesidades del lado del cliente.

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

Answer 3

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

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

Answer 4

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

Hasta el momento, no veo una diferencia muy grande el enfoque de usar algo como Ext, y otros como JQuery UI, Scriptaculous, MochiKit, etc.

Con Ext, el HTML es sólo un único marcador de posición - IU va aquí. A partir de entonces, todo se describe en JavaScript. La interacción DOM se minimiza bajo otra (quizás más fuerte) capa API.

Con los otros kits, me encuentro empezando por hacer un poco de diseño HTML, y luego extendiendo el DOM directamente con efectos llamativos, o simplemente reemplazando la entrada de formulario aquí, una adición allí.

Las principales diferencias comienzan a suceder ya que necesito ocuparme del manejo de eventos, etc. Como los módulos necesitan "hablar" entre ellos, me veo en la necesidad de alejarme del DOM, abstraerlo en pedazos.

Noto que muchas de estas bibliotecas también incluyen algunas técnicas de modularización interesantes también. Se incluye una descripción muy clara en el sitio web de Ext, que incluye a fancy way to "protect" your code with modules.

Un nuevo jugador que no he evaluado completamente es Sproutcore. Parece Ext in approach, donde el DOM está oculto, y en su mayoría desea tratar con la API del proyecto.

Answer 5

Tristan, encontrará que cuando intenta utilizar JavaScript de arquitectura como una aplicación MVC, tiende a quedarse 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. Puede estandarizar la forma en que pasa y recibe datos del servidor, pero en ese momento el modelo no pertenece realmente a JavaScript; pertenece a su aplicación del lado del servidor.

Vi un intento hace un tiempo cuando 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 un montón de datos para administrar el estado de la página actual. Sin embargo, en el momento de actualizar, se pierden todos esos datos. Probablemente estoy 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 compartimentalice sus "controladores". Normalmente lo hago colocándolos en archivos de origen 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 para el proceso de finalización de la compra. Esto tiende a mantener las cosas ligeras y fáciles de administrar.

Answer 6

Solo una aclaración rápida.

Es perfectamente factible escribir aplicaciones GWT que no estén orientadas al servidor. Asumo que desde Server-Oriented te refieres a GWT RPC que necesita un back-end basado en Java.

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

• El modelo era un gráfico de objetos. Aunque codifique en Java, en el tiempo de ejecución los objetos están en javascript sin necesidad de ninguna JVM en el cliente o en el servidor.GWT también es compatible con JSON con soporte completo de análisis y manipulación. Puede conectarse a servicios web JSON fácilmente, consulte 2 para obtener un ejemplo de combinación de JSON.
• La vista se compone de widgets estándar de GWT (más algunos de nuestros propios widgets compuestos)
• La capa del controlador estaba cuidadosamente separada de la vista mediante el patrón Observer.

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

Answer 7

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

El diseño de la arquitectura muy bien pensado. Hay 4 cosas que tendrá que hacer con JavaScript:

1. responder a un evento
2. Data Request/manipulan Servicios (Ajax)
3. Añadir información específica de dominio a la respuesta Ajax.
4. actualización el DOM

JMVC divide éstos en el modelo, patrón View, Controller.

En primer lugar, y probablemente la ventaja 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 usan el nombre del Controlador para limitar el alcance del funcionamiento del controlador. Esto hace que tu código sea determinista, lo que significa que si ves que ocurre un evento en un elemento '#todos', sabes 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){ ...} 
}) 

Siguiente 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 la funcionalidad específica del dominio (n. ° 3). Cuando se complete, puede usar modelos de su controlador como:

Todo.findAll ({después de: new Date()}, myCallbackFunction);

Finalmente, una vez que todos hayan regresado, tiene que mostrarlos (# 4). Aquí es donde usa 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 'views/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 alguna parte del ciclo de desarrollo con:

• Generadores de código
navegador integrado
• , selenio, y pruebas de Rhino
• Documentación de compresión
• Guión
• informe de errores