Contenido

corMVC, modelo MVC basado en jQuery

22 Dic

+ 5

El modelo MVC nos permite separar las diferentes capas de nuestros desarrollos de una forma clara, actualmente es la arquitectura más usada por los principales lenguajes de programación para generar frameworks que nos facilitan el trabajo.

cormvc-overview
(Ver Imagen)

Esa es la idea de corMVC, un framework jQuery que nos implementa esta tecnología. Para ello nos ofrece window.application con una serie de métodos para trabajar cómodamente con las diferentes capas.

Instalación

Para instalar el framework, y al estar basado en jQuery, debemos incluirlo previamente como vemos en el código:

<script type="text/javascript" src="jquery-1.3.2.min.js"></script>
<script type="text/javascript" src="application.js"></script>

Modo de empleo

mvc-workflow
(Ver Imagen)

Una vez instalado en nuestra página, podemos empezar a usar los métodos disponibles para difinir nuestro código.

Modelo

window.application.addModel((function( $, application ){

	function Contact( ){
		// ....
	};

	Contact.prototype.validate = function(){
		// ....
	};

	return( Contact );
})( jQuery, window.application ));

En este ejemplo, vemos como podemos definir el objeto que será usado como modelo en nuestra aplicación.

Controlador

window.application.addController((function( $, application ){

	function Controller(){
		// Rutas que dirigen nuestras acciones
		this.route( "/", this.index );
		this.route( "/contacts/", this.index );
		this.route( "/contacts/add/", this.addContact );
		this.route( "/contacts/edit/:id", this.editContact );
		this.route( "/contacts/delete/:id", this.deleteContact );
	};

	Controller.prototype = new application.Controller();
	Controller.prototype.init = function(){
		// Cargamos la vista
		this.contactFormView = application.getView( "ContactForm" );
	};
	Controller.prototype.addContact = function( event ){
		// Mostramos la vista
		this.showView( this.contactFormView, event );
	};
	Controller.prototype.editContact = function( event, id ){
		// ...
	};
	Controller.prototype.deleteContact = function( event, id ){
		// Cargamos el modelo
		application.getModel( "ContactService" ).deleteContact(
			id,
			function(){
				application.relocateTo( "contacts" );
			}
		);
	};
	ContactService.prototype.saveContact = function(){
		var self = this;
		// Ajax para grabar datos
		application.ajax({
			url: "...",
			data: {
				....
			},
			normalizeJSON: true,
			success: function( response ){
				if (response.success){
					// ...
				} else {
					// ...
				}
			}
		});
	Controller.prototype.index = function( event ){
		// ...
	};
	Controller.prototype.showView = function( view, event ){
		// ...
	};

	return( new Controller() );

})( jQuery, window.application ));

El controlador se encargará de redirigir nuestras acciones para interactuar con el modelo. Como podemos ver, indicamos las rutas asociadas a los métodos del controlador.

View

window.application.addView((function( $, application ){

	function ContactForm(){
		// Parámetros por defecto
		this.form = null;
		// ...
	};
	ContactForm.prototype.init = function(){
		var self = this;
		this.form = $( "#contact-form" );

		this.form.submit(
			function( event ){
				self.submitForm();
				return( false );
			}
		);
	};

	ContactForm.prototype.submitForm = function(){
		var self = this;

		// Obtenemos el modelo
		application.getModel( "Contact" ).saveContact(
			// ...
			function( id ){
                                // Redirigimos al controlador
				application.relocateTo( "contacts" );
			},
			function( errors ){
				self.applyErrors( errors );
			}
		);
	};
	return( new ContactForm() );
})( jQuery, window.application ));

La vista, nos permitirá dirigir los datos hacia y desde el usuario.

Templates

<script id="contact-list-item-template" type="application/template">
 <li>
   <div>
     <a>${name}</a>
   </div>
   <div>
     <a href="javascript:void( 0 )">more</a> &nbsp;|&nbsp;
     <a href="#/contacts/edit/${id}">edit</a> &nbsp;|&nbsp;
     <a href="#/contacts/delete/${id}">delete</a>
   </div>
   <dl>
     <dt>name:</dt>
     <dd>${name}</dd>
     <dt>phone:</dt>
     <dd>${phone}</dd>
     <dt>email:</dt>
     <dd>${email}</dd>
   </dl>
 </li>
</script>

Como buen framework, nos ofrece un motor de plantillas destinado para pintar la salida que la vista nos ofrece.

Aunque a simple vista parezca un poco engorroso, los que hayan usado alguna vez el modelo MVC sabrán que este código solo ofrece ventajas a la hora de trabajar con varios desarrolladores o para organizar el código de proyectos medianamente grandes.

  • El futuro. Los mvc en el cliente. Ya se que soy pesado con el tema pero sinceramente pienso que hay que pasar la lógica al cliente. Eso de crear HTML en el servidor no sentido. El servidor solo debe trabajar con json y el cliente con el resto. El cliente cada vez es mejor. Mejores navegadores, mejores motores de js.

  • @Gonzalo, muchos usuarios todavía usan IE5, IE6, incluso en navegadores de MS con versiones superiores, tienen problemas para utilizar un javascript de «alto nivel». Si añadimos toda la lógica en cliente, debemos tener siempre otra versión de servidor, para navegadores «no compatibles».

    Todo llegará. Pero de momento poco más. Sino díselo a Google, los problemas que han tenido con su Wave. Aunque han sido listos (tiene recursos para ello) y han creado plugins, addons, etc, para los demás navegadores y usar chrome como motor 🙂

    Bueno, lo dicho, estoy de acuerdo, pero todavía no es el momento.

  • @Gonzalo, si quieres que la lógica esté en el cliente, vuelve a las aplicaciones de escritorio tradicionales. La metodología que presenta este framework está muy chula para programas totalmente AJAX-izados, pero ni de coña vale para una aplicación compleja.

    No conviene ser extremistas con la distribución cliente-servidor. Aunque sólo sea por seguridad, delegar en el cliente quita cierto control (p. ej. validación de formularios). Intercambiar continuamente datos entre el servidor y JavaScript (XML, JSON, etc) es una forma diferente de hacer lo de siempre: procesamiento distribuido entre cliente y servidor, que es el camino trazado por el W3C y sus estándares. Para más «riqueza» tenemos Web Sockets, preferencias de privacidad y estándares para gráficos.

  • @Gonzalo, creo que el tema va por el lado de seguridad, convinando IE (ya que permite cross-domain) + Ajax, se puede enviar una masivamente datos con un simple script (JS), aunque tengas un captcha.
    Lo que tiene es que con JS (jQuery / RigthJS / Prototype / …) es muy facil y comodo trabajar el documento HTML.
    Creo que lo mejor es hacer la major cantidad de control en JS, pero de todas formas debes de controlar nuevamente los datos en el servidor.

  • A diferencia de todos , yo estoy de acuerdo con gonzalo. si pensamos en optimizar recursos del cliente hacia el servidor el modelo MVC es lo mejor, ademas hoy en día aquellos que les gusta vivir en el pasado a los dinosaurios que aun usan ie5 tienen que tener un poco mas de visión hacia el futuro y poner un poco mas de la suya para actualizarse en su tecnología, si bien es cierto que se pierde control como dicen, se puede implementar una doble comprobación de datos tanto en el lado del cliente como del servidor.
    saludos.

Comentar

#

Me reservo el derecho de eliminar y/o modificar los comentarios que contengan lenguaje inapropiado, spam u otras conductas no apropiadas en una comunidad civilizada. Si tu comentario no aparece, puede ser que akismet lo haya capturado, cada día lo reviso y lo coloco en su lugar. Siento las molestias.