Prácticas para modelos de dominio en Javascript (con marcos)

8

Esta es una pregunta con la que he estado de un lado a otro, y no he buscado ni encontrado nada: ¿cuáles son las prácticas aceptadas en torno a la duplicación de modelos de dominio en Javascript para una aplicación web, cuando se utiliza una ¿Marco como Backbone o Knockout?

Dada una aplicación web de un tamaño no trivial con un conjunto de modelos de dominio en el lado del servidor, ¿deberíamos duplicar estos modelos en la aplicación web (consulte el ejemplo en la parte inferior)? ¿O deberíamos usar la naturaleza dinámica para cargar estos modelos desde el servidor?

En mi opinión, los argumentos para duplicar los modelos están en facilitar la validación de los campos, asegurando que los campos que se espera que estén presentes estén presentes, etc. Mi enfoque es tratar el código del lado del cliente como una aplicación casi separada, haciendo cosas triviales y confiando solo en el servidor para datos y operaciones complejas (que requieren datos que el cliente no tiene). Creo que tratar el código del lado del cliente de esta manera es similar a la separación entre las entidades de un ORM y los modelos utilizados con la vista en la capa UI: pueden tener los mismos campos y estar relacionados con el mismo concepto de dominio, pero son distintos cosas.

Por otro lado, me parece que duplicar estos modelos en el lado del servidor es una clara violación de DRY y es probable que conduzca a resultados diferentes en el lado del cliente y del servidor (donde una parte se actualiza pero la otra no lo hace). Para evitar esta violación de DRY, simplemente podemos usar el dinamismo Javascripts para obtener los nombres de campo y los datos del servidor cuando sean necesarios.

Entonces: ¿existen pautas aceptadas sobre cuándo (y cuándo no) repetirte en estas situaciones? ¿O esto es algo puramente subjetivo, basado en el proyecto y los desarrolladores?

Ejemplo

Modelo del lado del servidor

class M 
{
    int A
    DateTime B
    int C
    int D = (A*C)
    double SomeComplexCalculation = ServiceLayer.Call();
}

Modelo del lado del cliente

function M(){
    this.A = ko.observable();
    this.B = ko.observable();
    this.C = ko.observable();
    this.D = function() { return A() * C(); }
    this.SomeComplexCalculation = ko.observalbe();
    return this;
}l
M.GetComplexValue = function(){
    this.SomeComplexCalculation(Ajax.CallBackToServer());
};

Me doy cuenta de que esta pregunta es bastante similar a this , pero creo que esto se trata más de desatar casi por completo la aplicación web del servidor, donde la pregunta es sobre hacer esto solo en el caso de cálculos complejos.

    
pregunta Andy Hunt 15.09.2013 - 21:52

2 respuestas

0

Creo que buenos patrones de diseño y un marco como Breeze pueden ayudarte. No repita el modelo de dominio en el cliente nuevamente, déjelo en el servidor, pero use Breeze para acercar el modelo al cliente.

Este es un gran ejemplo del uso de breezejs con el repositorio y la unidad de patrones de trabajo.

enlace

El modelo de dominio se mantiene en el servidor y Breeze lee los metadatos y crea las entidades localmente desde el servidor. Creo que esta es una gran solución para su problema. Obtiene acceso de tipo de marco de entidad local a través de JS y puede mantener su modelo en el servidor. Creo que tiene un buen balance de los problemas que mencionó en su pregunta.

    
respondido por el Roger Brogan 07.11.2013 - 21:48
3

Su pregunta real es un poco más general por lo que es difícil de responder, pero el ejemplo de validación de su formulario es un poco más específico, por lo que intentaré seguir con esa.

Como dijiste, siempre debes estar SECO, tanto como sea posible. Eso es algo bueno para tener en cuenta como desarrollador. Sin embargo, debes distinguir entre las cosas que son similares y debes evitar repetirlos con las cosas que hacen cosas similares, pero tienen Propósitos diferentes.

Vayamos a su ejemplo de validación de formulario. El propósito de su código de validación en el servidor es asegurarse de que tiene la dirección de correo electrónico del usuario, por ejemplo, para poner en la base de datos. Entonces, como es obligatorio para su proceso de registro tener la dirección de correo electrónico del usuario, lo verificará durante el proceso de registro.

¿Pero cuál es el propósito de su código JavaScript del lado del cliente? Sí, realiza la validación en el campo de entrada de correo electrónico, pero la idea general es: para verificar si el usuario ya ha ingresado su dirección de correo electrónico, si no se muestra una alerta ANTES ¡envíelo al servidor! Por lo tanto, el propósito de la validación de formularios del lado del cliente es dejar de enviar datos inútiles al servidor y mostrar un mensaje de error después de unos segundos para volver a enviar el formulario de solicitud. ¿Por qué? Porque es molesto para los usuarios. ¿Cree que debería mantener la función de validación de formularios solo en el servidor? No, porque tienen diferentes propósitos.

El propósito de la validación de formularios en el lado del cliente no es No puedo confiar en los usuarios, vamos a comprobarlo , pero es más una cuestión de UX en la que intenta evitar la comunicación. con el servidor solo para obtener el mensaje de error de validación; Sin embargo, el propósito de la validación de formularios en el lado del servidor es que no puedo confiar en los usuarios, veamos qué me piden que haga y un Usuario también puede ser una solicitud de API, sin ningún usuario humano en el lado del cliente.

Si lo ves así, el ejemplo de validación de tu formulario sería totalmente correcto, sin hacerte sentir WET.

Con respecto a su pregunta real, no intente mantener todo en el servidor o todo en el cliente; Realmente depende de la tarea. Digamos que si necesito analizar un archivo CSV grande-grande para el usuario y solo tengo cien usuarios en el sitio web y sé que tengo usuarios móviles, entonces puedo analizar ese archivo en el servidor y luego generar una copia correcta. -un-digerido marcado al cliente. Sin embargo, si tengo millones de usuarios, trataré de analizar el archivo en sus máquinas, usando sus navegadores web para usar su capacidad de procesamiento para evitar quemar nuestro servidor. Por lo tanto, la funcionalidad de análisis podría estar en el servidor o en el cliente, lo que tenga más sentido.

Sin embargo, si no estás seguro de dónde guardar tus cosas, entonces diría que las guardes en el servidor y luego entregues los resultados a los usuarios: evita el código duplicado tanto en el servidor como en el cliente.

    
respondido por el Mahdi 07.04.2014 - 09:45

Lea otras preguntas en las etiquetas