asp.net-mvc - ventajas - mvc ejemplos
¿Debería colocarse la lógica de clasificación en el modelo, la vista o el controlador? (13)
¿Quién controla el orden de clasificación?
(De Wikipedia )
1) orden natural dentro de los datos en sí:
El orden es parte del Modelo, por lo que debería ir allí. Una extracción en bruto de "todos los datos" devolvería los datos en el orden ordenado, y no hay interfaz para elegir el orden de clasificación.
2) El usuario debe controlar cómo ven los datos:
La Vista proporcionaría una interfaz (como flechas ascendentes / descendentes) que interactuaría con el Controlador, y el Modelo entiende los datos lo suficientemente bien como para hacer la clasificación solicitada en los datos. Sin embargo, una extracción cruda de los datos no necesariamente tiene que ser ordenada, a diferencia de (1).
En cualquier caso,
La Vista no comprende que esté sucediendo un tipo, mientras que la capacidad de mostrar qué orden de clasificación ha sido elegida. No pongas la lógica allí.
Pequeña advertencia
La funcionalidad de clasificación podría ir puramente en la Vista, bajo una circunstancia (que puedo pensar de forma directa, puede haber más):
Un tipo "tonto" donde todos los datos ya están en la vista y no tiene que usar ningún conocimiento de dominio para hacer el ordenamiento. Muy simple cadena o comparación de números, por ejemplo. Esto no es posible, por ejemplo, en los resultados de búsqueda en una página web cuando es probable que los resultados se dividan en varias páginas.
Tengo una lista desplegable que muestra los valores de una tabla para el usuario final. Me gustaría que estos valores se clasifiquen alfabéticamente.
De acuerdo con el diseño MVC correcto, ¿a qué capa debo colocar mi lógica de clasificación: el modelo, la vista o el controlador?
EDITAR : En respuesta a la pregunta de LarsH, "¿Quiere decir código que determina qué orden de clasificación se desea o código que realiza el tipo?", Originalmente me refería al código que determina qué orden de clasificación se desea.
(Nota: esta cita y cita se toma de la respuesta de @ dasblinkenlight , pero no estamos de acuerdo con nuestra interpretación. Lea su publicación y tome una decisión).
De acuerdo con la descripción de MVC ,
Un controlador puede enviar comandos a su vista asociada para cambiar la presentación de la vista del modelo (por ejemplo, al desplazarse por un documento). Puede enviar comandos al modelo para actualizar el estado del modelo (por ejemplo, editar un documento).
La lógica de clasificación (por ej., El algoritmo de clasificación / comparador de clasificación) pertenece al modelo, ya que contiene reglas comerciales y datos de estado. Como la forma en que se ordenan los datos del modelo cae directamente en la categoría "cambiar la presentación de la vista del modelo", el controlador es responsable de "hacer la ordenación" llamando al método model.changeSortedState ().
Aunque estoy de acuerdo en principio con la idea de que la clasificación es Business Logic porque al descomponerlo en su origen terminaría con algo así como "El cliente desea que la página del Producto se muestre con las imágenes ordenadas por fecha", entonces queda claro que el orden de clasificación de los datos generalmente no es arbitrario, incluso si no hay clasificación, ya que sigue siendo una decisión comercial por omisión (una lista vacía sigue siendo una lista).
PERO ... Esta respuesta no parece tener en cuenta los avances en la tecnología ORM, solo puedo hablar en relación con el Entity Framework (evitemos un argumento sobre si esto es cierto ORM, ese no es el punto) de Microsoft como eso es lo que uso, pero estoy seguro de que otros ORM ofrecen una funcionalidad similar.
Si creo una vista de Strongly Typed para una clase Product utilizando MS MVC y Entity Framework y existe una relación de clave externa entre la tabla Product e Image (por ejemplo, FK_Product_Image_ProductId), entonces, desde el primer momento, podría ordenar rápidamente las imágenes durante su visualización usando algo como esto en la vista:
@foreach(Image i in Model.Image.OrderBy(e => e.DisplayOrder)){ //etc etc... }
Se mencionó una capa específica de Business Logic, que también utilicé para realizar el 80% de mi lógica comercial, pero no voy a escribir una funcionalidad de clasificación en mi capa de Business Logic que imita algo que viene de fábrica. del Marco de la Entidad.
No creo que haya una respuesta correcta a esta pregunta, aparte de decir eso; debe abstraer la lógica empresarial compleja cuando sea posible, pero no a costa de reinventar la rueda.
De acuerdo con la descripción de MVC ,
Un controlador puede enviar comandos a su vista asociada para cambiar la presentación de la vista del modelo (por ejemplo, al desplazarse por un documento). Puede enviar comandos al modelo para actualizar el estado del modelo (por ejemplo, editar un documento).
De acuerdo con esto, la lógica de clasificación pertenece al controlador, ya que la alteración de la forma en que se clasifican los datos del modelo cae directamente en la categoría "cambiar la presentación de la presentación del modelo".
EDITAR: Para aclarar los malentendidos múltiples expresados en los comentarios, la "lógica de clasificación" no es el código que realiza el tipo; es el código que define el género. La lógica de clasificación compara elementos individuales entre sí para establecer un orden (por ejemplo, a través de una instancia de IComparator<T> ) o contiene lógica que construye un objeto para ser utilizado por un sistema externo (por ejemplo, a través de una instancia de IOrderedQueryable<T> ) Esta lógica pertenece a su controlador, porque necesita conocimiento relacionado con el lado "comercial" de su aplicación. Es completamente suficiente para realizar el tipo, pero está separado del código que realmente lo realiza . El código que ordena puede estar en su vista, en su modelo o incluso en la capa de persistencia que respalda su modelo (por ejemplo, su base de datos SQL).
De los tres que has enumerado, diría que pertenecen al controlador. Aunque no me gusta poner este tipo de lógica en el controlador. Normalmente creo una capa de servicio con la que se comunica el controlador que será responsable de comunicarse con el almacenamiento de datos y manejar la lógica de clasificación. Sin embargo, para aplicaciones pequeñas, está bien estar sentado en el controlador.
Definitivamente no es el controlador: envía mensajes para ver y modelar, pero debe hacer el menor trabajo posible. Si el usuario puede cambiar la clasificación, el controlador maneja esa solicitud informando al modelo o a la vista al respecto.
Tal vez la Vista si es una cosa pura Vista. Si la aplicación funciona igual de bien sin ordenar, la ordenación es solo parte de la representación y debe ir a la vista.
Si el orden es parte inherente del dominio, debe ir en el modelo.
Esta es una pregunta que se hace con asp.net en mente, pero como alguien mencionó a Rails, pensé que sería interesante considerar el problema en ese contexto. En Rails, es natural y bastante común realizar la clasificación junto con la recuperación como una acción de controlador, ya que el marco y la API ActiveRecord / ActiveQuery lo prevén. Por otro lado, es posible definir algún tipo de orden de clasificación personalizado para elementos estáticos y ponerlo en el modelo que utilizará el controlador, por lo que el modelo puede formar parte de la lógica de ordenamiento aunque no se lleve a cabo. la operación directamente. Sea lo que sea, puede ser seguro decir que generalmente se desaprueba al poner la lógica de ordenación en la vista.
Estoy un poco divertido de que algunas respuestas sean absolutamente contrarias a poner el género en el controlador o el modelo, y los encuentro demasiado pedantes para mi gusto, pero supongo que depende de la naturaleza del marco utilizado y las convenciones habituales asociadas con eso. También estoy de acuerdo con el comentario de Bill K de que tener la separación en primer lugar es más importante.
Normalmente lo haría en el controlador para mantenerme alineado con el patrón según las otras respuestas. Vea a continuación el razonamiento.
He estado reflexionando sobre esto y leyendo las respuestas y el material relacionado y pragmáticamente hablando, diría que dependerá de su aplicación, por ejemplo:
¿Es una aplicación mediana / grande y / o tiene varias UI asociadas (es decir, una aplicación de Windows, una interfaz web y una interfaz de teléfono).
- En este caso, probablemente construya una capa de servicio y la coloque en el objeto comercial y luego llame al método apropiado desde el controlador.
Si es un sitio web de UI único bien definido y está utilizando algo como EF Code First y no tiene o no tiene la intención de crear una capa de servicio y planea usar un método de extensión simple para lograrlo:
- En este caso, probablemente lo pondría en el controlador ya que pragmáticamente es la mejor opción en cuanto a tiempo / presupuesto.
Si es el mismo que el anterior PERO no se puede implementar con un método de extensión fuera de la caja.
- Bien puedo elegir mostrarlo en la clase de Modelo (si es verdaderamente a medida de ese tipo) ya que sería más apropiado aquí que en un controlador. Si el género se pudiera aplicar a más de una clase, lo implementaría en un método de extensión y luego lo llamaría en el controlador.
Para resumir:
Respuesta dogmática: Capa de servicio
Respuesta pragmática: por lo general, el controlador
Sugeriría ordenar los datos de una tabla, los datos que son lo suficientemente pequeños para ser útiles en una lista desplegable, deberían provenir del DB ya ordenado a través de la consulta. Para mí, eso hace que el modelo sea el lugar donde se aplica el género.
Si está decidido a hacer el tipo a mano, creo que hay buenos argumentos para usar el modelo o el controlador como su lugar preferido para la lógica. La limitación sería tu marco particular. Prefiero administrar los datos únicamente en el modelo. Uso el controlador para unir datos (modelo) y presentación (vista) como me enseñaron (auto).
Supongamos que tiene el sitio web de MVC, el sitio web de WebForms y una aplicación móvil.
Si desea que la ordenación sea coherente entre estas capas de presentación, entonces diría ordenar fuera de la capa de presentación. El servicio sería un buen candidato.
De lo contrario, almacenaría esa lógica en un modelo de vista. ¿Por qué? Porque será reutilizable y fácilmente comprobable.
Tu modelo debe contener datos.
Su vista debe contener la forma en que representa los datos.
Tu controlador debe contener la manipulación de tus datos.
Entonces la respuesta es el controlador, ya que la clasificación es definitivamente manipulación.
Ninguna de las anteriores. La clasificación es lógica de negocios y la lógica de negocios no pertenece a ninguno de los tres. No todos los códigos de su aplicación serán un modelo, vista o controlador.
Lo que generalmente hago en mis aplicaciones MVC es que tengo una capa de servicio que realiza toda la lógica comercial. Los métodos en la capa de servicio deben tener una API limpia y simple con parámetros bien nombrados. A continuación, puede invocar esos métodos desde su controlador para manipular los datos en los modelos.
En ese sentido, la clasificación está "en el controlador", pero el código en sí que hace la clasificación no debería implementarse en el controlador, solo se invoca desde allí.
- Las vistas son parte de MVC que se supone que contiene lógica de presentación.
- La capa del modelo es donde está contenida la lógica de negocios.
- Los controladores solo cambian el estado de ambos, según la entrada del usuario.
Entonces, la elección es: ¿cree que esto es parte de la lógica de negocio del dominio o la lógica de presentación?
Si estuviera implementando un MVC Model2 o un patrón MVC clásico, diría que el orden de los datos proporcionados por la capa del modelo debería ser activado por la solicitud de la vista a la capa del modelo. La vista pide datos ordenados, la capa del modelo lo proporciona.
Pero, como está utilizando la interpretación de ASP.NET MVC del patrón MVC, que es un poco diferente que su MVC estándar, la instancia de ViewModel debe solicitar información ordenada de la capa del modelo (por alguna razón, el marco ASP.NET cree que las plantillas deberían llamarse). "vistas" y vistas deben llamarse "viewmodels" ... es extraño).