¿Qué tan útil es una implementación de MVC "pura"?

Question

Trabajo en una empresa que ofrece software similar al 'CRM' personalizado. Actualmente, estamos rediseñando/desarrollando el software con la esperanza de que se vea más moderno y sea más fácil de desarrollar y personalizar para futuros clientes. Actualmente lleva mucho tiempo personalizar cada nueva aplicación.

Existe la presunción de que la razón por la que lleva tanto tiempo se debe a la cantidad de lógica empresarial que está presente en la capa 'vista'. Hasta cierto punto, puedo confirmar que esto es cierto, pero los síntomas no siempre indican de manera confiable una causa. Hubo una sugerencia de que si simplemente moviéramos la lógica de negocios a la capa de controlador y usáramos pure view (usamos java J2EE y struts) como implementando struts tags en lugar de llamar a la capa de bean e iterar objetos directamente en jsp - etc, etc.

Antes de comenzar a abogar por que sigamos adelante con esto, quería sentir lo que otras personas pensaban. ¿Una implementación "pura" del MVC (especialmente el énfasis en desacoplar el controlador y la vista) proporciona un código más limpio, más fácil de desarrollar y cambiar?

Gracias a todos ustedes por la entrada - que ha ayudado mucho

Answer 1

Su objetivo debe ser conseguir su lógica de negocio en un solo lugar. En mi experiencia, si puede hacer eso, su código base será más fácil de desarrollar, mantener y cambiar.

Modelo-vista-controlador es una forma de llegar a ese punto, aunque en MVC clásico, negocio lógica está en el modelo (dominio), mientras que la lógica de la aplicación está en el controlador.

Lógica de aplicación: si la siguiente fecha de inspección del usuario es dentro de una semana (o vencimiento), muestre la pantalla 'inspección de programación'; de lo contrario, muestre la pantalla 'historial de inspección'.

Business logic: los restaurantes que han fallado la inspección deben inspeccionarse cada seis meses, los restaurantes de mariscos deben inspeccionarse cada año y todos los demás restaurantes deben inspeccionarse cada dos años. Dada la última inspección de este restaurante, ¿cuándo vence su próxima inspección?

Answer 2

desacoplamiento siempre hace eso. No importa, MVC o no, cuanto menos acoplamiento haya en el sistema, más fácil será mantenerlo y cambiarlo. MVC es solo un buen patrón para Web, que simplifica el desacoplamiento, eso es todo.

Answer 3

Alguien dijo esto:

"Cualquier problema en la informática puede ser resuelto con otra capa de indirección"

Pero no me acuerdo quién es el autor de esta cita. ¿Cualquiera sabe?

Answer 4

MVC sugiere que la inteligencia se segregue apropiadamente. Eso implica que la vista y el modelo serían un poco tontos y que el controlador es el inteligente. Esta implicación nos permite crear modificaciones tontas y chicos inteligentes de una manera suave. Estos beneficios se cosechan enormemente cuando los requisitos/correcciones de código están efectivamente activados. Las abstracciones añadidas son un dolor hasta que uno comprende los patrones utilizados. Esto es MVC en el lado del servidor. ¿Qué pasa con MVC en el código de cliente final?

En ocasiones es muy cierto que los modelos de vista tienen una inteligencia diferente incorporada y están codificados en delegados comerciales. Sin embargo, un mejor enfoque es usar etiquetas personalizadas. Lo más molesto de las páginas jsp para mí ocurre cuando mezclan javascript con el código. Este código inteligente realmente intenta manipular el DOM y los resultados en etiquetas no coincidentes en el código jsp estático.

Como usted tiene el lujo de comenzar de cero. La vida sería más simple si todos usaran javascript no intrusivo (un idioma diferente al de Java y más fácil que la mierda que he visto en el código de producción) y etiquetas personalizadas (no tan difícil). Otro punto doloroso es no tener html/css compatible con W3C. Un gran ahorro de problemas con los problemas del navegador, si lo que son.

P.S: appologies para la larga perorata :)

Answer 5

Yo trabajo en una empresa que sigue MVC bastante estricto y hemos tenido mucho éxito con él. Hemos podido desarrollar servicios básicos que viven en el controlador y reutilizarlos en múltiples proyectos. Tener la capa de controlador también facilita la prueba unitaria y la reutilización del código también.