javascript - relaciona - Separación de la lógica del lado del cliente de la lógica del lado del servidor de forma reutilizable utilizando MVC
node js javascript en el lado del servidor pdf (6)
Antes de responder, esta pregunta es complicada:
- Estamos desarrollando en asp.net / asp.net mvc / jQuery pero estoy abierto a soluciones en cualquier plataforma usando cualquier marco
- Creo que la lógica como clasificar / ocultar columnas / reorganizar columnas / validación (donde tiene sentido) debe estar en el lado del cliente
- Creo que la lógica como buscar / actualizar los flujos de trabajo db / running debe estar en el lado del servidor (solo por razones de seguridad / depuración)
Lo que estamos tratando de hacer es NO CREAR UN MESS en nuestra UI escribiendo un montón de JavaScript para tratar la misma función en diferentes contextos. Entiendo que puedo usar un archivo JavaScript + JavaScript orientado a objetos, estoy buscando el patrón que lo haga todo más fácil.
Una solución propuesta fue tener un modelo de MVC tanto en el lado del cliente como del servidor, donde podemos encapsular la funcionalidad de JavaScript en los controladores del lado del cliente, y luego usarlos en diferentes partes del sitio. Sin embargo, esto significa que tenemos 2 implementaciones de MVC.
¿Es esto exagerado? ¿Cómo ampliarías esta solución? ¿Qué otras soluciones hay?
... Depende...
En realidad, lo mejor es desarrollar la interfaz de usuario usando css / javascript / html para un estilo / comportamiento / estructura + datos, en estos días la gente quiere interacciones ajax (ven cosas geniales en todas partes, por lo que esperan que no tengan que recarga páginas enteras cada vez), así que creo que deberías tomar esto en consideración. BTW MVC finaliza cuando se sirve su contenido, y no tiene que ser contenido HTML, puede servir xml o json en su Vista.
ASP.NET MVC permite devolver contenido ("TEXTO") para que pueda organizar su back-end usando MVC y la interacción / comportamiento del usuario en javascript, por ejemplo cuando se envía una llamada ajax al servidor al que llama el controlador de su aplicación , por lo que puede llamar a una acción Ajax que cambie a un modelo ajax que se represente como JSON y regrese a la parte JS de su UI (la parte de comportamiento).
Como la parte de Comportamiento está definida en su parte de Vista (la Vista inicial está compuesta de CSS / HTML JS), siempre que sea una parte de presentación , creo que no ha roto los patrones de MVC.
PD. Me estaba olvidando de decir que, obviamente, las acciones de BD permanecen en su modelo (puede pensar en el modelo como el lugar donde permanece la capa de acceso a datos + capa de objetos comerciales)
En dos; siempre debe tener la validación del lado del servidor, así como la validación del lado del cliente
En tres; si puede encontrar una forma de manipular la base de datos en el lado del cliente sería impresionante;)
No sé cómo funciona ASP.net, así que solo estoy hablando de mi experiencia en PHP.
Escribiría controles emparejados por código de servidor y cliente. Cada control necesita una forma, lógica del lado del cliente y lógica del lado del servidor. El formulario está escrito por su motor de plantillas, la lógica del lado del cliente se adjunta al formulario y se escribe en JS y la lógica del lado del servidor es un par de controlador / acción en algún lugar que manipula el modelo. Claramente, no querrás unir tu lógica del lado del cliente a una acción / controlador específico, así que asegúrate de definir una interfaz que se pueda usar para hablar con tu control ...
Luego, para cada formulario escribiría una clase en javascript que instancia tus controles. Por ejemplo; usted puede tener un control:
{include file = "list_view.php" id = "ListView1" data = $Data.List}
que imprimiría tu formulario. Luego en tu clase de controlador de página:
this.ListView1 = new ListViewController({id : "ListView1", serverCtrl : "Users"});
Ahora puede usar "this.ListView1" para manipular la vista de lista. El controlador de vista de lista hace cosas como hacer consultas AJAX para páginas nuevas si el uso presiona el botón de la página siguiente y también maneja columnas y clasificación (que también se delegará en el servidor).
Acabo de buscar en Google esto, así que tómalo con un grano de sal. JavascriptMVC pretende ser un framework MVC. Una vez más, no tengo experiencia con él pero puede valer la pena verlo.
Si está utilizando MVC, supongo que su vista utiliza un motor de plantillas. Cada página está asociada a una plantilla, y cada plantilla generalmente contiene una referencia a uno o más scripts. La pregunta es, ¿cómo se referencian sus scripts en la plantilla? ¿Son estáticos o son dinámicos? Dentro de sus controladores, debe tener la opción de incluir cualquier script en la vista utilizada para una página independientemente de la plantilla. A menudo sugiero este enfoque de "incluirlo cuando sea necesario" porque simular el lado del cliente MVC significa exactamente lo que dijo que significa: ahora tiene que mantener dos marcos MVC. No solo eso, con la mayoría de los modelos del lado del cliente tienen acceso directo a su modelo del lado del servidor, lo que frustra el propósito de su MVC del lado del servidor. Ahora está pasando por alto el controlador por completo.
Cuando se trata de JavaScript, lo mejor es mantenerlo muy simple. Con jQuery, tienes muchas más posibilidades de que esto suceda. Cada página obtiene el núcleo, y usted tiene varios otros archivos de JavaScript en la misma carpeta, cada uno de los cuales es un complemento o una extensión del objeto jQuery que se asigna a una funcionalidad muy específica. Si los desarrolladores quieren saber si la funcionalidad ya existe, todo lo que hacen es verificar el sistema de archivos donde se encuentran los archivos JavaScript. Si el complemento existe, inclúyalo en el controlador para usarlo en una página. De esta forma, puede crear ayudantes en el lado del servidor que se encuentran entre la aplicación del lado del cliente y los controladores existentes. El asistente es específico de esa funcionalidad y complemento, y no abre el acceso general a sus modelos desde el lado del cliente.
Mantenlo simple. Cree su aplicación para que sea completamente funcional en el marco de MVC ASP.Net. No se requiere JavaScript en esta etapa de prueba.
Ahora agregue las cosas agradables al vincular jQuery en su site.master (enlace de Google) y en la parte inferior de sus Vistas que requieren una experiencia web 2.0, enlace a los archivos JS apropiados que agreguen la funcionalidad discretamente. Apague JS y su aplicación se degrada de nuevo al paso anterior.
Por ejemplo, desea agregar validación del lado del cliente además del lado del servidor. El archivo JS adjuntaría un controlador de eventos a los formularios en el momento de la publicación. El controlador usaría un objeto generado por el servidor (el mismo objeto utilizado para la validación del servidor) que sería mejor como un objeto JSON porque es compatible con JS y ASP.NET. Los miembros del objeto serían las reglas para verificar y los mensajes de error para escribir en el DOM en la misma ubicación en la que optó por los errores del lado del servidor. Su controlador devuelve falso hasta que todo sea válido y verdadero cuando sea correcto.
Desea una buena característica elegante, como una vista de caja de luz de sus imágenes. Agregue un complemento para su vista, modifique el marcado <ul id="lightup">
..., agregue el código:
$(function() { $(#lightup).showit(400); // or something like that });
y eres bueno para ir.
Intente separar la funcionalidad compartida de su código de servidor en un servicio web o página para que el cliente, a través de XHR y el servidor, pueda compartir la misma funcionalidad / datos.
no devuelva json / xml a las vistas y compórtelas con la generación de dom jquery en el cliente. Está bien en cuanto al rendimiento en máquinas decentes, pero cometí este error y cuando intento ver el sitio con mi iPhone, tarda 60 segundos en cargar ... ¡y soy la única persona en el sitio! :-)
así que en este momento solo uso jquery dom injection para las actualizaciones de ajaxy y no renderizo toda la página.