Quando as regras de negócios afetam a apresentação no MVC

O padrão de design do MVC deve levar à separação das regras de negócios da apresentação.

Às vezes, porém, as regras de negócios afetam a apresentação. Qual é a melhor maneira de lidar com isso? É quando um ViewModel deve ser usado?

Por exemplo, voltando ao meu aplicativo de biblioteca inexistente, um bibliotecário está digitalizando livros devolvidos. O sistema indica que um livro está atrasado e aplica uma multa a esse consumidor.

Certos funcionários podem ter segurança para substituir essa multa com base em determinadas condições.

A camada de apresentação do meu aplicativo de biblioteca precisará permitir que o funcionário defina a multa como 0 ou clique em um botão para substituí-la.

Mas os funcionários que NÃO têm segurança para fazer isso devem ver a taxa como uma entrada desativada ou talvez apenas como leitura.

Observe que a segurança pode não ser a única regra comercial . Este é apenas um exemplo. Por exemplo, meu aplicativo pode ter informações de configuração definidas em algum lugar que faz com que um campo na tela se torne desnecessário etc.

Embora o código possa permitir que qualquer pessoa altere a multa e mostre uma mensagem de validação, essa não é uma boa experiência do usuário.

Qual é uma boa prática para fazer isso? As opções em que posso pensar (usando o ASP.NET MVC) são:

1. Faça com que a própria exibição verifique a regra de negócios e desative ou ative o campo.

2. Use uma função HTMLHelper que implemente a apresentação para o campo fino e faça com que a função auxiliar verifique a regra de negócios.

3. Faça com que o controlador verifique a regra de negócios e use uma visão diferente.

4. Faça com que o controlador verifique a regra de negócios e defina uma propriedade no ViewBag que indica se o campo está ativado.

5. Usar um ViewModel verifica a regra de negócios e define as informações indicando que o campo está ativado.

As opções 1 e 2 fazem com que a camada de apresentação precise validar regras de negócios e isso atrapalha as coisas.

A opção 3 causará duplicação de esforços, pois agora você tem duas visualizações definidas.

As opções 4 e 5 exigem que a camada de apresentação saiba que o campo PODE ser ativado ou desativado, mas não POR QUE. Eu acho que gosto mais de 4 ou 5.

Nossas outras opções em que não estou pensando?

Eu acho que a sua opção número 5 é a melhor, mas com alguns ajustes:

Você ViewModeldeve ter uma propriedade que indique se os dados podem ser atualizados ou não. Talvez uma propriedade booleana "CanOverrideLateFine".

O que quer que esteja criando o ViewModel (seu Controller, ou mais provavelmente um serviço comercial ao qual o Controller delega) é responsável por avaliar as regras de negócios e definir essa propriedade. Não é o próprio ViewModel.

O Viewinspecionará a propriedade "CanOverride" e determinará como renderizar corretamente para o usuário. Ele pode ser tão simples como ativar ou desativar um campo de formulário, mas pode ser algo completamente diferente (talvez nem mesmo tornando o campo, ou o fornecimento de um elemento visual completamente diferente).