asp.net mvc training A lógica de classificação deve ser colocada no modelo, na visualização ou no controlador?




simulado 70-486 (10)

Eu tenho uma lista suspensa que exibe valores de uma tabela para o usuário final. Eu gostaria que esses valores fossem classificados em ordem alfabética.

De acordo com o design MVC adequado, em qual camada devo colocar minha lógica de classificação: o modelo, a exibição ou o controlador?

EDIT : Em resposta à pergunta de LarsH, "Você quer dizer código que determina qual ordem de classificação é desejada? Ou código que executa o tipo?", Eu estava originalmente se referindo ao código que determina qual ordem de classificação é desejada.


De acordo com a descrição do MVC ,

Um controlador pode enviar comandos para sua visão associada para alterar a apresentação da visão do modelo (por exemplo, percorrendo um documento). Ele pode enviar comandos ao modelo para atualizar o estado do modelo (por exemplo, editando um documento).

De acordo com isso, a lógica de classificação pertence ao controlador, porque alterar a maneira como os dados do modelo são classificados cai diretamente na categoria "alterar a apresentação da visão do modelo".

EDIT: Para esclarecer vários mal-entendidos expressos nos comentários, a "lógica de classificação" não é o código que executa o tipo; é o código que define o tipo. A lógica de ordenação compara itens individuais entre si para estabelecer uma ordem (por exemplo, através de uma instância de IComparator<T> ) ou contém uma lógica que constrói um objeto a ser usado para ordenar por um sistema externo (por exemplo, através de uma instância de IOrderedQueryable<T> ). Essa lógica pertence ao seu controlador, porque ele precisa de conhecimento relacionado ao lado "comercial" do seu aplicativo. É totalmente suficiente para executar a classificação, mas é separado do código que realmente o executa . O código que ordena pode estar em sua visão, em seu modelo ou até mesmo na camada de persistência que apóia seu modelo (por exemplo, seu banco de dados SQL).


(Nota: esta citação e citação é retirada da resposta do @ dasblinkenlight , mas nós discordamos da nossa interpretação, leia o seu post e faça a sua própria opinião).

De acordo com a descrição do MVC ,

Um controlador pode enviar comandos para sua visão associada para alterar a apresentação da visão do modelo (por exemplo, percorrendo um documento). Ele pode enviar comandos ao modelo para atualizar o estado do modelo (por exemplo, editando um documento).

A lógica de classificação (por exemplo, o algoritmo de comparação / classificação de classificação) pertence ao modelo, pois contém regras de negócios e dados de estado. Como alterar a maneira como os dados do modelo são classificados se enquadra na categoria "alterar a apresentação da visão do modelo", o controlador é responsável por "fazer a classificação" chamando o método model.changeSortedState ().


Suponha que você tenha o site do MVC, o site WebForms e um aplicativo móvel.

Se você quiser que a classificação seja consistente entre essas camadas de apresentação, eu diria que classifique fora da camada de apresentação. O serviço seria um bom candidato.

Caso contrário, eu armazenaria essa lógica em um modelo de exibição. Por quê? Porque será reutilizável e facilmente testável.


Nenhuma das acima. A classificação é lógica de negócios e a lógica de negócios não pertence a nenhuma das três. Nem todo pedaço de código em sua aplicação será um modelo, visão ou controlador.

O que geralmente faço em meus aplicativos MVC é que tenho uma camada de serviço que executa toda a lógica de negócios. Os métodos na camada de serviço devem ter uma API simples e limpa com parâmetros bem nomeados. Você pode então invocar esses métodos de seu controlador para manipular os dados nos modelos.

Nesse sentido, a ordenação está "no controlador", mas o próprio código que faz a classificação não deve ser implementado no controlador, apenas invocado a partir daí.


Esta é uma pergunta feita com o asp.net em mente, mas como alguém mencionou o Rails, achei que seria interessante considerar o problema nesse contexto. No Rails, é natural e bastante comum executar a ordenação junto com a recuperação como uma ação do controlador, já que o framework e o ActiveRecord / ActiveQuery fornecem provisões para ela. Por outro lado, é possível definir algum tipo de ordem de classificação personalizada para itens estáticos e colocar isso no modelo a ser usado pelo controlador, para que o modelo possa desempenhar um papel na lógica de classificação mesmo que não execute a operação diretamente. Seja o que for, pode ser seguro dizer que colocar a lógica de classificação na visão é geralmente desaprovada.

Estou um pouco achando que algumas respostas são absolutamente contra colocar o tipo no controlador ou no modelo, e eu as acho muito pedantes para o meu gosto, mas suponho que isso depende da natureza do framework usado e das convenções usuais associadas ao isto. Eu também concordo com o comentário de Bill K de que ter a separação em primeiro lugar é mais importante.


Definitivamente não é o controlador: ele envia mensagens para visualizar e modelar, mas deve fazer o mínimo de trabalho possível. Se o usuário pode alterar a classificação que a solicitação é manipulada pelo controlador, informando o modelo ou a visão sobre ele.

Talvez o View seja uma coisa pura do View. Se o aplicativo funciona tão bem sem ordenar, a classificação é apenas parte da representação e deve ser exibida.

Se a ordenação é parte inerente do domínio, deve ir no modelo.


Dos três que você listou, eu diria que pertence ao controlador. Eu realmente não gosto de colocar esse tipo de lógica no controle, no entanto. Eu geralmente crio uma camada de serviço com a qual o controlador se comunica e que será responsável pela comunicação com o armazenamento de dados e pela manipulação da lógica de classificação. Para pequenas aplicações, é bom estar sentado no controlador, no entanto.


Embora eu concorde, em princípio, com a idéia de que classificar é Business Logic porque, ao dividi-lo em sua origem, você teria algo como "O cliente gostaria que a página do produto fosse exibida com as imagens ordenadas por data". a ordem de classificação dos dados geralmente não é arbitrária - mesmo que não haja classificação, pois ainda é uma decisão de negócios por omissão (uma lista vazia ainda é uma lista).

MAS ... Estas respostas não parecem levar em conta os avanços na tecnologia ORM, eu só posso falar em relação ao Entity Framework (vamos evitar um argumento sobre se isso é verdade ORM, que não é o ponto) da Microsoft como é isso que eu uso, mas tenho certeza que outros ORMs oferecem funcionalidade semelhante.

Se eu criar uma exibição do tipo Strongly Typed para uma classe Product usando o MS MVC e o Entity Framework e houver uma relação de chave estrangeira entre a tabela Product e Image (por exemplo, FK_Product_Image_ProductId), eu seria capaz de classificar rapidamente as imagens durante a exibição usando algo parecido com isso na exibição:

@foreach(Image i in Model.Image.OrderBy(e => e.DisplayOrder)){ //etc etc... }

Houve menção a uma camada de Business Logic específica, que também uso para executar 80% da minha lógica de negócios, mas não vou criar funcionalidade de classificação na minha camada de lógica de negócios que imita algo que vem de fábrica. do Entity Framework.

Eu não acho que há uma resposta correta para essa pergunta, além de dizer isso; você deve abstrair a lógica complexa de negócios sempre que possível, mas não ao custo de reinventar a roda.


Gostaria de sugerir a classificação de dados de uma tabela de dados que é pequena o suficiente para ser útil em uma lista suspensa, deve vir do banco de dados já classificado através da consulta. Para mim, isso faz do modelo o lugar onde o tipo é aplicado.

Se você está determinado a fazer o tipo manualmente, acho que há bons argumentos para usar o modelo ou o controlador como seu ponto preferido de lógica. A limitação seria o seu quadro particular. Eu prefiro gerenciar dados apenas no modelo. Eu uso o controlador para casar dados (modelo) e apresentação (visão) como eu fui (auto) ensinado.


  • Visualizações são a parte do MVC que deve conter a lógica de apresentação.
  • Camada de modelo é onde a lógica de negócios está contida.
  • Os controladores alteram apenas o estado de ambos, com base na entrada do usuário.

Portanto, a escolha é: você acha que isso faz parte da lógica de negócios do domínio ou da lógica de apresentação.

Se você estivesse implementando um MVC Model2 ou um padrão MVC clássico, então diria que a ordenação de dados fornecida pela camada de modelo deve ser acionada pela solicitação da visualização para a camada de modelo. A tela pede dados ordenados, a camada de modelo fornece isso.

Mas, como você está usando a interpretação do padrão MVC da ASP.NET MVC, que é um pouco diferente, o MVC padrão - a instância ViewModel deve solicitar informações ordenadas da camada de modelo (por algum motivo, a estrutura do ASP.NET acha que os modelos devem ser chamados "views" e views devem ser chamadas "viewmodels" .. é estranho).







model-view-controller