model-view-controller - tutorial - programar en mvc

¿Cuál es el uso del modelo en MVC? ¿Es realmente útil?

Question

Soy nuevo en esto, así que tengan paciencia conmigo. He estado usando un marco MVC en un par de proyectos últimamente, y después de un tiempo, estoy desilusionado con la utilidad percibida del "Modelo" en MVC.

Obtengo la utilidad de Controladores y Vistas, sé que la separación entre presentación y lógica es importante para hacer que el código sea más mantenible en el futuro, aunque no necesariamente más rápido o más robusto.

Si toda la lógica se colocara dentro del controlador en primer lugar, no veo ningún uso para el Modelo, especialmente el Registro Activo. Ya tenemos un lenguaje tan robusto y fácil de usar para comunicarnos con la base de datos, ¿verdad? Se llama SQL. Para mí, cuando los modelos se implementan como registro activo, su utilidad depende de si desea que su aplicación se ajuste a múltiples bases de datos.

Entonces, lo que pregunto es si solo estás usando una base de datos, ¿por qué molestarse con los Modelos y los Registros Activos? ¿Por qué no usar simplemente SQL? ¿Por qué la capa extra de complejidad? ¿Tienen estudios de caso / historias de la vida real donde los modelos realmente pueden hacer las cosas mejor que simplemente usando la clase de base de datos y el SQL-away?

Nuevamente, lo siento si parece ser tan ignorante, pero realmente no sé por qué los modelos son importantes. Gracias por responder.

Answer 1

¡No es una pregunta ignorante en absoluto! Solo el hecho de que lo preguntes en lugar de simplemente ignorar toda la teoría de MVC y hacer lo que desees es agradable. :-)

Para responder a su pregunta: conceptualmente, los modelos simplemente proporcionan una buena abstracción para sus datos. En lugar de pensar en términos de "cómo escribo esta combinación interna para obtener todos los campos que necesito", los modelos le permiten pensar en términos de "cómo se relacionan los objetos de mi aplicación entre sí, cómo interactúan y cómo puedo obtener los datos que necesito de ellos ".

De la misma manera que las Vistas y los Controladores lo ayudan a separar la presentación de la lógica, los Modelos lo ayudan a separar la lógica de la aplicación (desde la perspectiva de un usuario, de todos modos) en cuanto a de dónde provienen sus datos y cómo se representan internamente.

Para dar un ejemplo más específico (si no es completamente realista): en teoría, podría escribir toda su aplicación de una manera en la que obtuvo todos los datos a través de consultas SQL. Pero luego se dio cuenta de que quería usar algún motor noSQL (CouchDB, etc.) porque necesitaba una escala horizontal.

Con los modelos (y un marco que puede usar ambos tipos de almacenamiento, por supuesto :-)) no tendría que preocuparse por los detalles, ya que todos sus datos importantes ya están representados de manera genérica a través de sus modelos y tanto vistas como los controladores pueden actuar sobre esa representación.

Sin ellos, probablemente tendrías que volver a escribir una gran parte del código para adaptar la búsqueda de datos al nuevo servidor.

Y eso es sólo en la parte de almacenamiento aburrido. Con SQL puro, es mucho más difícil definir las interacciones entre los objetos de su aplicación (es decir, la lógica de negocios) porque simplemente no hará eso en SQL (probablemente, de todos modos).

No es una explicación perfecta (ni mucho menos), pero espero que ayude.

Answer 2

En la mayoría de las situaciones de la vida real, los datos que provienen del usuario no van directamente a la base de datos.

A menudo debe ser validado, filtrado o transformado.

El rol de la capa del modelo es, por lo general, asegurarse de que los datos lleguen correctamente a la tienda de back-end (generalmente la base de datos) mediante la realización de estas operaciones, que no deben ser responsabilidad del controlador (controlador delgado, modelo grueso), y no la responsabilidad del propio motor de base de datos.

En otras palabras, la capa Modelo es responsable, o "sabe", cómo deben manejarse los datos.

La mayoría de los marcos MVC modernos proporcionan formas de especificar contratos sobre los requisitos de validez de los datos, como Rails.

Aquí hay un ejemplo de http://biodegradablegeek.com/2008/02/introduction-to-validations-validation-error-handling-in-rails/ :

class Cat
  validates_inclusion_of :sex, :in => %w(M F), :message => ''must be M or F''
  validates_inclusion_of :vaccinated, :in => [true,false]
  validates_inclusion_of :fiv, :in => [true,false]
  validates_inclusion_of :age, :within => 1..30
  validates_each :weight do |record, attr, value|
      record.errors.add attr, ''should be a minimum of 1 pound'' if value and value  /^[01][0-9]//[0-9]{2}//[0-9]{4}$/
  validates_length_of :comment, :allow_blank => true, :allow_nil => true, :maximum => 500
end

Aquí, varios de los requisitos de validez de los datos no pueden ser manejados por la base de datos, y no deben manejarse en los controladores, ya que cualquier modificación en esos requisitos puede romper el código en varios lugares.

Por lo tanto, el modelo es el mejor lugar para asegurarse de que los datos sean coherentes para su dominio.

Hay mucho más que decir al respecto, pero tuve ganas de abordar un punto que me parece importante, motivado por la experiencia práctica :)

Answer 3

Los modelos deben contener toda tu lógica. El controlador solo es responsable con la lógica relacionada con la interacción del usuario. Todas las funciones relacionadas con el dominio (lo que se conoce como "lógica de negocios") deben colocarse en el modelo y desacoplarse del código del controlador. De esta forma puede lograr una mejor separación de inquietudes y reutilización del código.

Por ejemplo, supongamos que está escribiendo una aplicación para permitir a los usuarios ingresar información sobre sí mismos y recibir recomendaciones de dieta.

Por un lado, pondría el código relacionado con la transformación de los datos provistos por el usuario en una lista de recomendaciones de dieta en la parte del modelo. Esto incluye el acceso a la base de datos, pero también cualquier cálculo, algoritmos y procesamiento relacionados con el problema en cuestión (el dominio del problema).

Por otro lado, coloca el código para registrar a los usuarios, muestra un formulario, recopila los datos del formulario, lo valida, en el controlador. De esta manera, por ejemplo, más tarde podría agregar una api a su aplicación (que utiliza un código diferente para la autenticación, obtener datos del usuario, validación, etc.) y reutilizar el código para generar los resultados (del modelo).

Este es solo un ejemplo de para qué sirve el modelo.

Answer 4

Primero, está asumiendo que una capa de modelo necesariamente usa algún tipo de ORM para abstraer el SQL. Esto no es cierto: puede crear una capa de modelo que no esté bien acoplada desde la capa del Controlador pero que esté estrechamente acoplada a un DBMS en particular, y así evitar el uso de un ORM con todas las funciones.

Hay algunas bibliotecas de ORM, como Hibernate (Java), NHibernate (.NET), Doctrine (PHP) o ActiveRecord-Rails (Ruby) que realmente pueden generar todas las declaraciones de SQL reales para usted; pero si cree que ORM es innecesario y desea definir todas las declaraciones SQL a mano, no las use.

Sin embargo, en mi humilde opinión, esto NO significa que deba colocar toda la lógica relacionada con su base de datos dentro de la capa del controlador. Esto se conoce como el enfoque del "controlador gordo", y es un camino que conduce, muchas veces, a códigos inflados e imposibles de mantener. Podría usarlo para proyectos CRUD simples, pero cualquier cosa más allá de eso exigirá la existencia de un "Modelo" real.

Parece que te importa MVC. Por favor, lea también algo sobre TDD. Un hombre sabio dijo una vez "el código heredado es un código sin pruebas ". Cuando descubra que las pruebas unitarias automatizadas son tan importantes como el código "real", comprenderá por qué hay tantas capas en una aplicación empresarial y por qué su capa de modelo debe estar separada del controlador. Un bloque de código que intenta hacer todo (presentación, lógica de negocios, persistencia de datos) simplemente no se puede probar (ni eliminar por el camino).

Editar

"Modelo" es un término un poco borroso. Dependiendo de dónde se mire, puede significar algo ligeramente diferente. Por ejemplo, los programadores de PHP y Ruby lo usan con frecuencia como sinónimo de un registro activo , lo cual no es exacto. Algunos otros desarrolladores parecen creer que un "modelo" es solo un tipo de DTO , lo cual tampoco es correcto.

Prefiero usar la definición de modelo como se ve en Wikipedia :

El componente central de MVC, el modelo, captura el comportamiento de la aplicación en términos de su dominio de problemas, independientemente de la interfaz de usuario. El modelo gestiona directamente los datos, la lógica y las reglas de la aplicación.

Así que el modelo es la capa más grande e importante en la mayoría de las aplicaciones MVC. Es por eso que generalmente se divide en subcapas: Dominio, Servicio, Acceso a datos, etc. El modelo generalmente se expone a través del dominio, porque es allí donde encontrará los métodos a los que llamará su controlador. Pero la capa de acceso a datos también pertenece al "Modelo". Todo lo que esté relacionado con la persistencia de datos y la lógica empresarial le pertenece.

Answer 5

Siempre relaciono el modelo con los datos, independientemente de dónde esté presente o cómo se represente. En MVC V muestra datos y C maneja cambio. Incluso si tiene todos los datos que se presentarán en la pantalla en un HashMap dentro de su controlador; ese HashMap será llamado el Modelo.