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




simulado 70-486 (8)

Quem controla a ordem de classificação?

(Da Wikipedia )

1) Ordem natural dentro dos dados em si:

A ordem faz parte do modelo, por isso deve ir lá. Um pull raw de "todos os dados" retornaria os dados na ordem classificada e não há interface para escolher a ordem de classificação.

2) O usuário deve controlar como eles veem os dados:

A Visualização forneceria uma interface (como setas ascendentes / descendentes) que interagem com o Controlador, e o Modelo entende os dados bem o suficiente para fazer a classificação solicitada nos dados. No entanto, uma puxada bruta dos dados não precisa necessariamente ser ordenada, diferentemente de (1).

Em ambos os casos,

O modo de exibição não entende que há um tipo acontecendo, outro que a capacidade de mostrar qual direção de classificação foi escolhida. Não coloque a lógica lá.

Pequena advertência

A funcionalidade de ordenação poderia ir puramente na visão, sob uma circunstância (que eu posso pensar de improviso; pode haver mais):

Um tipo "burro" em que todos os dados já estão na exibição e não precisam usar nenhum conhecimento de domínio para fazer o tipo. Cadeia muito simples ou comparação de números, por exemplo. Isso não é possível, por exemplo, nos resultados da pesquisa em uma página da Web quando os resultados provavelmente serão divididos em várias páginas.

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.


(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 ().


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.


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.


Eu normalmente faria isso no controlador para permanecer alinhado com o padrão de acordo com as outras respostas. Veja abaixo o raciocínio.

Eu venho meditando sobre isso e lendo as respostas e o material relacionado e, pragmaticamente falando, eu diria que isso dependeria da sua aplicação, por exemplo:

É uma aplicação média / grande e / ou tem várias UI's associadas (isto é, uma aplicação Windows, interface Web e interface do telefone).

  • Nesse caso, eu provavelmente construiria uma camada de serviço e a colocaria no objeto de negócios e, em seguida, chamaria o método apropriado do controlador.

Se é um site de interface de usuário único bem definido e você está usando algo como o EF Code First e você não tem ou não tem intenção de criar uma camada de serviço e planeja usar um método de extensão simples para alcançá-lo:

  • Neste caso, eu provavelmente colocaria no controlador como pragmaticamente o melhor ajuste em relação ao tempo / orçamento.

Se é o mesmo que o acima, mas não pode ser implementado com um método de extensão fora da caixa.

  • Eu posso escolher estourá-lo na classe Model (se é realmente indicado para esse tipo único), pois seria mais apropriado aqui do que em um controlador. Se a classificação puder ser aplicada a mais de uma classe, eu a implementaria em um método de extensão e a chamaria no controlador.

Resumindo:

Resposta dogmática: camada de serviço

Resposta pragmática: geralmente o controlador


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í.





model-view-controller