validação

Validação em aplicações web

0

Pessoal, com o tempo eu venho testando diferentes maneiras de realizar validação dos dados para determinada execução de um método de negócio ou funcionalidade semelhante. Em projetos anteriores ao asp.net mvc u já passei pelos seguintes modelos:

 

Validação apenas no client side
Este modelo é inviável para uma aplicação enterprise, pois toda a regra de execução está no layout, se uma nova interface fosse criada regras teriam que ser copiadas e adicionadas ao novo projeto. Com o tempo aprendi que a validação client-side(app web) é apenas para melhorar a interação do cliente com a aplicação e que uma validação no lado servidor é necessária para segurança da aplicação.

Validação client-side e server side
Desta maneira temos a validação client-side para melhorar a interface com o usuário e ainda temos a validação do lado servidor capaz de validar a execução. Neste modelo a validação server side pode ser reaproveitada em outros projetos de interface. No entanto já tive problemas com duplicação de código de validação que era difícil de manter.

Validação client-side e server side *(usando façades)
Usando o último modelo decidi por criar uma camada de validação usando um Validation facade, tentando assim isolar código de validação da minha regra de negócio efetivamente. Cheguei a usar com sucesso o modelo de validação até que chegou a integração asp.net mvc+ data annotations

Validação usando Data annotations(client side e server side)
Usando data annotations é possível manter informações de validação na propria entidade(classe) e ainda reaproveitar o código tanto para client-side  e server side. Ai tudo parecia perfeito! mas e quando eu criar um novo projeto de interface sem suporte ao data annotations? deveria escrever um código para funcionar com data annotations em outra interface como uma app WCF. então..

Validação usando Data annotations+ enterprise library 5.0
A versão 5.0 do enterprise library tem suporte ao data annotations, então agora poderia reaproveitar o data annotations para projetos mvc usando a estrutura que já existe e ainda poderia usar data annotations em outras interfaces através do entlib e ter a mesma qualidade /padrão de informar dados inválidos(nome do campo+mensagem). E se quiser poderia usar a validação do mvc com o entlib.

Novo modelo proposto com Data annotations + enterprise library 5.0 + code contracts
Estou na fase de definição do modelo de validação de um novo projeto, estou pensando em adotar o último modelo adotado quando estiver trabalhando com métodos que recebem entidades como parâmetros que podem ser validadas. Nos casos de métodos que apenas recebem parâmetros vou usar code contracts para definir e alertar quais validações devem ser realizadas para a execução ocorrer com sucesso.

Questões sobre o modelo proposto

Eu ainda estou estudando algumas opções neste modelo, o que fazer por exemplo quando o usuário passa uma  id que deveria ser da tabela pessoa e o ID não existe? a interface de usuário deveria possibilitar a seleção correta do id? como o negócio deveria se comportar? lançando uma exceção?

Quem deve validar? a função que chama ou a função chamada?

0

Fala galera, desta vez  vamos falar sobre a responsabilidade de validação dos dados. Quem deve validar, a função que está sendo chamada ou a função que chama?Acho que este é um assunto defendido de diversas maneiras por nós, programadores. Eu não fazia a mínima idéia antes de conhecer o design por contrato(DBC). No DBC contratos são realizados e todas as partes  envolvidas devem respeitar o contrato. Se você ainda não conhece o DBC pode olhar um pouco aqui e aqui. Basicamente o contrato é estabelecido indicando o que a função precisa receber(validade dos parâmetros) e o que ela vai retornar quando recebe os parâmetros necessários. Os contratos podem ser feitos com ferramentas como o CodeContracts ou até com comentários,Vamos olhar um exemplo usando comentários

   1: public class Calculadora

   2:     {

   3:

   4:         /// <summary>

   5:         /// Realiza a divisão entre dois numeros

   6:         /// </summary>

   7:         /// <param name="dividendo">Pode ser qualquer valor</param>

   8:         /// <param name="divisor">Pode ser qualquer valor exceto 0</param>

   9:         /// <returns></returns>

  10:         public static Decimal Dividir(Decimal dividendo, Decimal divisor)

  11:         {

  12:             return dividendo / divisor;

  13:         }

  14:     }

Bem, na pior das hipóteses o desenvolvedor sabe  que a validação deve ser feita antes de chamar a função apresentada, além disso sabe que se passar os parâmetros corretos vai obter uma resposta valida. As coisas ficam mais legais quando você está usando ferramentas como o CodeContracts.

Além da notificação ao usuário da função fica relativamente mais fácil de escrever testes para validar o contrato da função,  temos em mente quais contratos devem ser respeitados e quais não devem. Uns exemplos de testes contra o contrato.

   1: [TestClass]

   2:     public class CalculadoraTeste

   3:     {

   4:

   5:         [ExpectedException(typeof(DivideByZeroException))]

   6:         [TestMethod]

   7:         public void TesteDividir_DividindoPorZero()

   8:         {

   9:             Calculadora.Dividir(10, 0);

  10:         }

  11:

  12:         [TestMethod]

  13:         public void TesteDividir_ValorMaximo()

  14:         {

  15:             Assert.AreEqual(1, Calculadora.Dividir(Decimal.MaxValue, Decimal.MaxValue));

  16:         }

  17:         public  void  TesteDividir_parametrosSimples()

  18:         {

  19:             Assert.AreEqual(10, Calculadora.Dividir(100, 10));

  20:

  21:         }

  22:

  23:     }

Bem, com o DBC aprendi este modelo de desenvolvimento onde na maioria das vezes o cliente deve fazer a validação antes da chamada do método. Os principais benefícios desta abordagem são relacionados à separação de responsabilidades. Quando o cliente valida os dados é possível criar por exemplo uma camada Fachada responsável pelas validações e isolar o Núcleo do sistema que agora não se preocupa mais com códigos de validação. O legal do facade é quando você ainda consegue aproveitar ele em diversos ambientes diferentes, por exemplo trabalho em um projeto onde o Facade é utilizado via Ajax, assim a validação cliente e servidor não fica duplicada.

Outro beneficio legal é a maior facilidade de propagar erro e invalidade dos dados, afinal de contas você vai estar uma camada mais próxima do cliente, não precisa ficar propagando erros por N camadas.

Concluindo, O DBC me ensinou uma maneira legal de validar os dados. Nos projetos em que trabalho gosto da idéia do projeto fachada apesar de ter que escrever mais código ficou feliz em eliminar a duplicidade de validações.

Adicional: você ainda pode gerar testes beaseados em contratos, olhe esta ferramenta.

A way to use facades

0

Hello folks, Today in the morning I was reading my email when I saw an interesting post at  dotnetarchitects. This post is a discussion about facades and its implementation. A lot of people gave their tips, I also recommend you have a look, I gave my tip too. My tip was based in my experience when using facades.

I’m working in a project called comperio, in this project I have been trying to be a junior architect. We(dev Team) thought that would be nice if we had a layer that could do all validations and if  these validations were ok this layer could call the layer that knows how to process the operation.We had decided to use a Facade layer to do these validations, but this facade layer were an server-side layer and we thought, should we do the same code in client side to improve the UX ? after some discussion we decided to use the facade layer to do the validation in both. So we write an action  that calls the validate method in facade and it worked fine.

A facade was used because we think that the business logic layer should work as system’s core. Thus any error that could be avoided should avoid before enter in the system’s core. If you look our architecture you can see that the UI project has a reference to Facade project and nothing more. So, every layer or application that wants to use our system’s core must call our facade. The other reason to do it was that we want provide an API, an this API cant use core resources without some validations.

This approach is a simple way to implement validation, if you agree the idea that validation should be done in client and server side. Other cool tip I read was the use of keys in the assembly so we can ensure that the UI project is Using the Facade project.

Validando campo hora

0

Fala galera, estava aqui pensando em uma maneira simples e eficiente de validar um campo de hora(AM/PM) em uma das telas do sistema. Pra ser sincero procurei primeiro em inglês..Estava perdendo tempo, tive a idéia de usar uma expressão regular para validar o campo hora.

Expressão: ^([0-1][0-9]|[2][0-3]):([0-5][0-9])$

Validador do asp.NET configurado:

É isso galera.. Até mais…

Go to Top