none
Como discernir 'regras de negócios' de 'validações' - Aplicação em camadas RRS feed

  • Pergunta

  • Bom dia amigos(as) do fórum.

    Estou iniciando agora com programação em camadas e estou achando muito interessante, porém muito confuso. 

    Tenho uma camada de negócios BLL, uma DTO, uma GUI e outra DAO. 

    Muitos de meus amigos costumam criar classes genéricas para validarem cpf, campos que não podem ficar vazios, tamanhos de caracteres, etc... Preciso validar os seguintes itens:

    1 - Campos que não podem ficar vazios e devam conter uma limitação de caracteres;

    2 -  Campos  cujo preenchimento deverá ser obrigatório;

    3 - Validar se o CEP, CPF/CNPJ estão corretos.

    Quais campos são considerados uma regra de negócio e quais campos são apenas validações?

    Como em implemento isso na classe BLL?

    Abração!!!! :)

    quarta-feira, 2 de dezembro de 2015 09:47

Respostas

  • Entendo que validações envolvendo preenchimento e número de caracteres devam ser realizadas na interface gráfica. O que vc pode fazer de maneira adicional, neste caso, é colocar certas restrições na base (campos NOT NULL, por exemplo).

    Pelo menos em projetos Web que trabalho é isto que costumo fazer. Agora uma validação como deixar salvar apenas se o cliente não tiver um CPF já cadastrado anteriormente, é algo que vc implementaria em sua camada BLL. Neste caso, já temos uma regra de negócio e não uma simples validação.

    Espero ter ajudado.

    • Marcado como Resposta Jalber Romano quinta-feira, 10 de dezembro de 2015 17:50
    quinta-feira, 10 de dezembro de 2015 11:08

Todas as Respostas

  • Validações podem ser regras de negócio (como informar um código de pedido que tenha sido aprovado). Entendo que as validações que vc está com dúvida sejam mais genéricas, não ligadas diretamente a negócio.

    Algo como validação de CNPJ ou CPF, checando se o número é realmente válido. Nestes casos, ao invés de inserir isto na camada de negócio, vc poderia criar uma biblioteca (Class Library) com classes utilitárias, nas quais estas validações genéricas ficariam definidas e poderiam ser reutilizadas em outros projetos.

    Espero ter ajudado.

    Abs

    • Sugerido como Resposta Renato GroffeMVP quarta-feira, 2 de dezembro de 2015 12:39
    quarta-feira, 2 de dezembro de 2015 12:39
  • Obrigado pela ajuda Renato....

    Entendi... Só mais uma dúvida:

    Digamos que eu tivesse duas funções na camada BLL sendo uma para Inserir e outra para  dar Update para manipular uma Pessoa Física. Toda a vez que eu fosse salvar ou atualizar, eu tivesse que validar se o campo IDCidade (preenchimento Obrigatório), campo RazaoSocial (Preenchimento Obrigatório e não pode ser maior que 100 caracteres)... Como eu validaria isso de forma correta e mostrasse para o usuário Um MessageBox?

    -----------Camada BLL-------------------

    private readonly DAL.Repositoy.PessoaFisicaRepository _PessoaFisicaRepository = new DAL.Repositoy.PessoaFisicaRepository();
    
            public String Salvar(PessoaFisicaDTO pPessoaFisicaDTO)
            {
                return _PessoaFisicaRepository.Salvar(pPessoaFisicaDTO);
            }
    
            public String Atualizar(PessoaFisicaDTO pPessoaFisicaDTO)
            {
                return _PessoaFisicaRepository.Atualizar(pPessoaFisicaDTO);
            }


    • Editado Jalber Romano quarta-feira, 9 de dezembro de 2015 12:44
    quarta-feira, 9 de dezembro de 2015 12:06
  • Entendo que validações envolvendo preenchimento e número de caracteres devam ser realizadas na interface gráfica. O que vc pode fazer de maneira adicional, neste caso, é colocar certas restrições na base (campos NOT NULL, por exemplo).

    Pelo menos em projetos Web que trabalho é isto que costumo fazer. Agora uma validação como deixar salvar apenas se o cliente não tiver um CPF já cadastrado anteriormente, é algo que vc implementaria em sua camada BLL. Neste caso, já temos uma regra de negócio e não uma simples validação.

    Espero ter ajudado.

    • Marcado como Resposta Jalber Romano quinta-feira, 10 de dezembro de 2015 17:50
    quinta-feira, 10 de dezembro de 2015 11:08
  • Entendo... existem algumas validações que não se encaixam como regras de negócios, mas imagine se vc estiver validando algo em um campo na camada BLL e ele tiver que parar a execução para o usuário corrigir e depois voltar a gravar ou alterar novamente.... na camada BLL muita gente usa um throw new exception e estoura erros feios para o usuário... fiz até uma postagem sobre isso:

    https://social.msdn.microsoft.com/Forums/pt-BR/af784d02-c23b-44a6-a61f-0e99ca10ac4d/dvida-sobre-implementao-de-regras-de-negcio-e-validaes-na-camada-bll-c?forum=504

    Como eu poderia validar com messageBox's mais amigáveis para o usuário?

    quinta-feira, 10 de dezembro de 2015 17:54
  • Gerar exceções é algo que deve ser analisado com cuidado, já que há um consumo adicional de memória. Eu procuro criar status descrevendo cada falha ou outras situações específicas e, a partir disso, gerar mensagens de erro mais amigáveis.

    O lançamento de exceção deve ocorrer em casos nos quais vc precise interromper uma ação, algo que se caracterizaria como um estado inválido. Logo, para regras de negócio o ideal é criar algum tipo de estado através de um enum, por exemplo.

    sexta-feira, 11 de dezembro de 2015 15:14