mvc - todos los frameworks de javascript

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 hasta el punto en que una organización, o me atrevo a decirlo, "arquitectura" es necesaria. Mi primer enfoque es "MVC-ish":

• El ''modelo'' es un árbol JSON que se extiende con ayudantes
• La vista es el DOM más clases que lo modifican
• El controlador es el objeto donde conecto el manejo de eventos y el inicio de la vista o la manipulación 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 ... solo en el enfoque de "javaScript + <servicio web genérico -y cosa aquí">

Nota: antes dije javaScript "no es realmente OO, no es 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.

Considera esto:

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

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

Utilicé 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 el estado separado.

Answer 2

No estoy 100% seguro de lo que quiere decir aquí, pero diré que después de hacer ASP.NET durante los últimos 6 años, mis páginas web ahora están principalmente impulsadas por JavaScript una vez que el servidor hace la renderización básica de la página. Utilizo JSON para todo (lo he estado haciendo durante aproximadamente 3 años) y uso MochiKit para mis necesidades del lado del cliente.

Por cierto, JavaScript es OO, pero como usa herencia prototípica, las personas no le dan 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, eche un vistazo a 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 me di cuenta de que, si bien MochiKit tiene una sintaxis muy expresiva, no me resultaba tan cómodo como Prototype / Scriptaculous o jQuery para mí.

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

Answer 4

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 JQuery UI , Scriptaculous , MochiKit , etc.

Con Ext, el HTML es solo un marcador de posición único: la interfaz de usuario va aquí. A partir de ese momento, 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.

Observo que muchas de estas bibliotecas también incluyen algunas técnicas de modularización interesantes. Se incluye 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 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ás que cuando tratas de 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 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 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 grafo de objeto. 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 los servicios web JSON fácilmente, vea 2 para obtener un ejemplo de mashup 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. La próxima GWTQuery que funciona con GWT 1.5 puede cambiar eso aunque no en un futuro próximo debido a la abundancia de complementos para jQuery.

Answer 7

JavaScriptMVC es una excelente 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 harás con JavaScript:

1. Responda a un evento
2. Solicitar datos / manipular servicios (Ajax)
3. Agregue información específica de dominio a la respuesta de ajax.
4. Actualiza el DOM

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

Primero, 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){ ...}
})

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 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 vuelvan, debes 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. Te ayuda en cualquier parte del ciclo de desarrollo con:

• Generadores de código
• Pruebas integradas de navegador, selenio y rinoceronte
• Documentación
• Compresión de script
• Error al reportar