O View não deve executar validação?

Eu estava lendo " No MVC, um modelo deve lidar com a validação? " Porque estava curioso para saber onde a lógica de validação deveria ir em um site do MVC. Uma linha na resposta principal é a seguinte: "os controladores devem lidar com a validação, os modelos devem lidar com a verificação".

Eu gostei disso, mas fiquei me perguntando por que não faríamos a validação de dados no View, por vários motivos:

1. As visualizações geralmente têm um suporte robusto de validação (bibliotecas JS, tags HTML5)
2. As visualizações podem validar localmente, reduzindo as E / S da rede
3. A interface do usuário já foi projetada com o tipo de dados em mente (calendários para datas, giradores para números), tornando-se um pequeno passo na validação

A validação em mais de um local é contrária ao conceito do MVC de isolar responsabilidades; portanto, "faça isso nos dois" parece inadequado. Fazer validação de dados apenas no controlador é realmente a abordagem dominante?

Eu não acho que exista um único lugar onde você possa dizer que toda a validação deve ir. Isso ocorre porque temos algumas estratégias de programação concorrentes diferentes trabalhando juntas em um site asp.net mvc padrão.

Primeiramente, temos a idéia de separar a lógica do domínio em modelos, a lógica da 'ação' em controladores e a exibição em uma Visualização. Isso se baseia na idéia de que toda a lógica ocorrerá no servidor com o navegador, simplesmente fornecendo uma renderização da exibição.

Em seguida, estendemos a visualização usando o javascript do lado do cliente. Isso está tão avançado hoje em dia que a idéia de 'site de uma página' com Jquery / knockout / angular é prática comum.

Essa prática pode ser equivalente a escrever um aplicativo completo do lado do cliente, que implementa um padrão MVC ou MVVM. Denegrimos a exibição para um objeto de transferência de dados e o controlador para um terminal de serviço. Movendo toda a lógica de negócios e da interface do usuário para o cliente.

Isso pode proporcionar uma melhor experiência ao usuário, mas você precisa confiar em um cliente essencialmente não confiável. Portanto, você ainda precisa executar a lógica de validação no servidor, independentemente de quão bem seu cliente pré-valide suas solicitações.

Além disso, geralmente temos requisitos de validação que não podem ser executados pelo cliente. por exemplo. "meu novo ID é único?"

Qualquer aplicativo que você criar com o objetivo de fornecer a melhor experiência / desempenho necessariamente precisará emprestar vários paradigmas de programação e comprometerá-os para atingir seu objetivo.

A validação em mais de um local é contrária ao conceito do MVC de isolar responsabilidades; portanto, "faça isso nos dois" parece inadequado.

Poderia haver várias responsabilidades de validação a serem consideradas aqui? Como você disse no seu nº 3:

A interface do usuário já foi projetada com o tipo de dados em mente (calendários para datas, giradores para números), tornando-se um pequeno passo na validação

Então talvez seja:

Visualização : Valide o tipo de entrada, formato, requisito ... validação básica de entrada do usuário que não tem nada a ver com a lógica de negócios. Pegue todo esse material fofo antes de gerar tráfego de rede, fazendo uma solicitação ao servidor.

Modelo : valide as preocupações comerciais dos dados. Isso é um valor legal de acordo com as regras de negócios? Sim, é um valor numérico (garantimos isso na exibição), mas faz sentido?

Apenas um pensamento.

Vou assumir que você precisa de validação para persistência.

Não apenas View, mas Model também não deve lidar com validação. Durante meus dias na área de TI, percebi que o DDD é uma das maneiras de garantir que você esteja realmente fazendo as coisas corretamente, ou seja. as classes são realmente responsáveis ​​pelo que deveriam ser.

Ao seguir o design orientado a domínio, seus modelos incluem sua lógica de negócios, e é isso. Mas eles não incluem validação, por que não?

Vamos supor que você já esteja tão longe quanto está usando, em Data Mappervez de Active Recordpersistir na camada de domínio. Ainda assim, você deseja que os modelos sejam validados, portanto, adicione a validação ao seu modelo.

interface Validation
{
    public function validate();
}

class ConcreteModel extends MyModel implements Validation
{
    public function validate() { // the validation logic goes here }
}

A lógica de validação garante que você possa inserir corretamente o modelo no seu banco de dados MySQL ... Alguns meses se passam e você decide que deseja armazenar seus modelos também nos bancos de dados noSQL, bancos de dados que exigem regras de validação diferentes das do MySQL.

Mas você tem um problema, você tem apenas 1 método de validação, mas precisa validar um Modelde 2 maneiras diferentes.

Os modelos devem fazer o que são responsáveis , cuidar da lógica de negócios e fazê-lo bem. A validação está ligada à persistência, não à lógica de negócios, portanto validação não pertence a um modelo .

Você deve criar Validators, que usará um modelo para validar em seu construtor como parâmetro, implementar a Validationinterface e usá-los Validatorpara validar seus objetos.

interface Validation
{
    public function validate();
}

class MySQLConcreteModelValidator implements Validation
{
    public function __construct(ConcreteModel $model) { }

    public function validate()
    {
        // you validate your model here
    }
}

class RedisConcreteModelValidator implements Validation
{
    public function __construct(ConcreteModel $model) { }

    public function validate()
    {
        // you validate your model with different set of rules here
    }
}

Se a qualquer momento no futuro decidir que você deseja adicionar outro método de validação para outra camada de persistência (porque você decidiu que Redis e MySQL não são mais o caminho), você apenas criará outro Validatore usará seu IoCcontêiner para obter a instância correta. no seu config.

Para muitos desenvolvedores, o modelo Fat contra o Stupid Ugly Controllers é o método preferido.

O conceito básico no texto é

... Lembre-se sempre de que o Model não é apenas o banco de dados. Até os dados obtidos dos serviços da web podem ser expressos como um modelo! Sim, até Atom alimenta! Estruturas que apresentam introduções ao Modelo, quase nunca explicam isso antecipadamente, o que apenas exacerba mal-entendidos.

e

A exibição deve se preocupar apenas em gerar e apresentar uma interface do usuário para que os usuários possam se comunicar com a intenção do modelo . Controladores são os orquestradores que convertem as entradas da interface do usuário em ações no Modelo e devolvem a saída de qualquer Vista que tenha sido informada do (s) Modelo (s) apresentado (s). Os controladores devem definir o comportamento do aplicativo apenas no sentido em que mapeiam a entrada do usuário em chamadas no Models, mas além dessa função, deve ficar claro que todas as outras lógicas do aplicativo estão contidas no Model. Controladores são criaturas humildes com um código mínimo que apenas preparam o cenário e deixam as coisas funcionarem de maneira organizada.

A visualização deve se preocupar apenas em gerar e apresentar uma interface do usuário para que os usuários possam se comunicar com a intenção do modelo é a parte importante. Um modelo deve definir os dados armazenados, por isso também deve ser responsável por verificar a validade dos dados.

Ao gravar o registro de uma pessoa, cada pessoa deve ter um número de identificação único fornecido pelo país. Essa verificação (geralmente) é feita pela UNIQUEverificação de chave pelo banco de dados. Cada número de ID fornecido deve satisfazer algumas etapas de controle (a soma dos dígitos ímpares deve ser igual à soma dos dígitos pares etc.). Esse tipo de controle deve ser feito peloModel

O controlador está coletando dados Modele transmitindo-os Viewou revertendo-os, coletando os dados do usuário Viewe transmitindo-os para Model. Qualquer restrição de acesso e validação dos dados não deve ser feita pelo Controller. Foi Controllerquem recolhe os dados do cookie e foi oModel que verifica se é uma sessão válida ou se o usuário tem acesso a essa parte do aplicativo.

Viewé a interface do usuário que coleta dados do usuário ou apresenta dados para o usuário. Verificações simples podem ser feitas pelo endereço de e-mail deView entrada do usuário ou não (portanto, isso também pode ser feito na Visualização) IMO.

A vista é do lado do cliente e você não deve pressionar a entrada do usuário. Javascripts podem falhar ao executar no lado do cliente, um usuário pode usar scripts manuscritos para alterá-los ou desativar o script usando o navegador. Você pode definir scripts de validação do lado do cliente, mas nunca deve aplicá-los e fazer a verificação real na Modelcamada.

As visualizações devem realizar validações para fins de ff:

1. ) Uma validação de front-end pode reduzir o tráfego de dados no seu servidor.
2. ) lida com dados inválidos antes que eles possam viajar no seu servidor.
3. ) se você deseja uma segurança mais alta, é melhor uma combinação de validação de front-end e back-end.