Re: [dotnetarchitects] ASP.NET MVC 3 e melhores praticas na validação.

[João Bateloche]

Sinceramente o IsValid() não me agrada nem um pouco.

Me parece no minimo estranho uma entidade saber se validar, e a partir do momento em que você adiciona um método de validação na própria entidade, você está dizendo que esta em algum momento pode manter um estado inválido, o que normalmente indica um erro de design, e também está deixando totalmente de lado qualquer prática de programação defensiva, pois qualquer desenvolvedor que esquecer de chamar o IsValid() em seu código estará adicionando um bug ao sistema.

Sem contar que o exemplo do artigo é totalmente baseado em um modelo anêmico, e mesmo separando os assemblies o "domínio" ainda está acoplado à apresentação, uma vez que a exibição depende do atributo "display" nas propriedades do domínio.

Em 25 de julho de 2012 15:33, Victor Santos <victors...@gmail.com> escreveu:

Olá,

Gostaria de saber a opinião de vocês sobre a forma como foi implementada a validação no artigo bem legal do Andre Baltiere.

http://andrebaltieri.net/2012/01/15/desenvolvendo-aplicaes-para-diferentes-cenrios-com-asp-net-mvc-e-ef-parte-3service-pattern/ 

Como podem ver ele removeu as validações da entidade (dataannotations) e levou para a camada de serviço atraves do metodo IsValid que será apresentado para cada entidade.

O problema é que perdemos validação client-side via jquery.validation, como recuperar neste cenário? Além disso vocês conseguiram entender o valor em criar esta camada Service Pattern?

Abraços!

--
Você recebeu esta mensagem porque faz parte do grupo .Net Architects hospedado no Google Groups.
Para postar envie uma mensagem para dotnetar...@googlegroups.com
Para sair do grupo envie uma mensagem para dotnetarchitec...@googlegroups.com
Para mais opções visite o grupo em http://groups.google.com/group/dotnetarchitects?hl=pt-br

[edmilson hora]

João, fiquei curioso, que pratica vc adota para evitar que a entidade faça sua propria validação?

---

De: João Bateloche <jbate...@gmail.com>
Para: dotnetar...@googlegroups.com
Enviadas: Segunda-feira, 30 de Julho de 2012 23:28
Assunto: Re: [dotnetarchitects] ASP.NET MVC 3 e melhores praticas na validação.

[Daniel Moreira Yokoyama]

Acho que ele se expressou mal, Edmilson. Pela forma como ele fala, tudo leva a crer que ele coloca a validação no construtor. O que é exatamente o que eu faço.

[Igor]

Olá, a um tempo atrás um colaborador aqui do grupo me indicou o Fluent Validation 3.
É o que eu uso para o mvc é estou muito satisfeito. Ele desacopla totalmente a sua entidade (ou dto, ou viewmodel) da validação.

Eu removo o provider do dataannotations, e adiciono o provider do Fluent Validation com injeção de dependencia tudo funciona muito bem.

[Daniel Moreira Yokoyama]

O problema é que se estas validações servem para dizer que sua entidade é válida (duh) então este "acoplamento" que você removeu é uma dependência da entidade e não faz sentido tirar dela. (A menos, é claro, que você esteja usando o modelo anêmico e pretende manter assim).

Alguns "acoplamentos" existem simplesmente porque estão no lugar certo. Tirar eles de lá pode ser uma péssima escolha.

Atenciosamente,

Daniel Moreira Yokoyama.

@dmyoko

http://twitter.com/dmyoko

 

Blogs:

Getting Sharper (C#, Arquitetura de Software e outras coisas mais)
http://gettingsharper.wordpress.com/

 

Eis o Cristo... e jaz o Cristão (Cristianismo sem Religiosidade)

http://eisocristo.wordpress.com

 

Stay Sharp!

[Priscila Mayumi Sato]

Palavra de noob:

eu acho que o Daniel tem razão :)

Vejo umas pessoas querendo deixar suas classes cada vez mais desacopladas até chegar um ponto que elas nem fazem mais sentido de existir.

--
Atenciosamente
Priscila Mayumi Sato

[Igor]

Validações de campos é interface com usuário. Ainda não se trata de estado válido da entidade, e sim do tentar garantir que o usuário que esta usando não vá digitar um valor errado ou fora de logica.

Também não faz sentido eu deixar a minha entidade dependente dessas validações. Quem tem que ficar dependente desta referente é a tier de validação.
Essas validações geralmente em MVC são feitas com DataAnnotations que te obriga a decorar atributos nas classes. Dei uma solução para não usar esses atributos.

Fluent Validation funciona para o MVC como o Fluent API para o Entity Framework.

[Winston Pacheco Junior]

Não vejo problemas em ter Annotations nos ViewModels.

Assim como não vejo problema em validar novamente as coisas no domínio, evitando a criação de objetos inválidos ao invés do IsValid.

O jeito que ele pretende usar o ORM é meio estranho, mas deve servir no contexto dele (que é só dar um exemplo de como as coisas devem funcionar) espero que as pessoas pensem direito sobre o uso de um ORM, a melhor estratégia para ele, para o uso da sessão e essas coisas que toda hora as pessoas falam e sempre terminam usando errado, ainda assim...

[Daniel Moreira Yokoyama]

Cara... tier de validação? É exatamente o contrário do que estou falando.

Claro que você pode (e deve) refletir estas validações no client, afim de poupar os roundtrips desnecessários para validar os dados. Mas se o meu Cliente precisa ter um Nome required com o maxlength de 50 caracteres, então isso precisa estar na minha classe Cliente, caceta... se ela não se valida, quem validará? sua tier de validação? E a classe cliente faz o que então? Se salva no banco?

Pôxa, isso é uma dependência da classe que precisa estar na classe (Tell Don't Ask). Não faça os outros decidirem o que ela vai fazer... é ela que decide.

Atenciosamente,

Daniel Moreira Yokoyama.

@dmyoko

http://twitter.com/dmyoko

 

Blogs:

Getting Sharper (C#, Arquitetura de Software e outras coisas mais)
http://gettingsharper.wordpress.com/

 

Eis o Cristo... e jaz o Cristão (Cristianismo sem Religiosidade)

http://eisocristo.wordpress.com

 

Stay Sharp!

[Rafael Uchôa]

Igor,

Como você faz para obter a cobertura de teste unitário das regras usando o Fluent Validation ?

Pelo o que vi, as regras podem ser criadas no construtor de uma classe {Entity}Validator, e assim teremos problemas para obter a cobertura dos testes para regras criadas usando essa abordagem.

Em 31 de julho de 2012 08:25, Igor <oro...@gmail.com> escreveu:

[Felipe Zini]

Eu concordo que uma classe do meu domínio só deve existir se ela for válida. Porém, num cenário onde tenho 1:N onde é obrigatório a existência de pelo menos um item deste relacionamento, não sei exatamente como poderia validar. Construtor? Eu deveria receber em meu construtor essa coleção?

Um Curso tem N Módulos, e o meu Curso só é válido se ele pertencer ao menos a 1 módulo. Eu sei como validar isso, porém, me confunde um pouco se faço do jeito """correto""".

2012/7/31 Rafael Uchôa <rafaeluc...@gmail.com>

--
http://about.me/felipezini

[Winston Pacheco Junior]

Eu concordo contigo Daniel. Gosto de Design By Contract, não acho legal classes com estados inválidos.

Talvez você possa me esclarecer como que você faz as suas regras refletirem na UI Sem ter nenhuma repetição de algum tipo de validação.

Eu programo mais Back End e Desktop, manter os estados das classes válidos é bem mais simples para mim do que para alguém que desenvolve Web. Como você faz para refletir suas validações na sua página?

E quanto a essa pergunta: "E a classe cliente faz o que então? Se salva no banco?", no exemplo do Blog, ela não faz nada.... O service faz tudo por ela.

[João Bateloche]

Pessoal, não vamos confundir ViewModel e domínio, são coisas diferentes...

Em 31 de julho de 2012 13:44, Winston Pacheco Junior <winston...@gmail.com> escreveu:

[Winston Pacheco Junior]

Não tem confusão alguma da minha parte.

Apenas disse que colocava os Annotations no viewmodel (para ter uma validação cliente) e valido novamente na hora de criar minhas classes do domínio. Simples assim.

[João Bateloche]

Sim, por isso é um modelo anêmico.

No exemplo as classes não tem comportamento, são apenas um container para refletir os dados da tela, mais parecido com uma ViewModel do que com uma entidade propriamente dita.

[Winston Pacheco Junior]

Então, talvez isso tenha gerado a dúvida do email anterior.

Eu não desenvolvo usando DDD (nem conheço direito, nunca "pratiquei" digamos assim) mas minhas classes tem toda a inteligência necessária ao domínio da mesma. Classes totalmente procedurais que só servem para esconder o ORM (como as do exemplo) não fazem sentido algum para mim.

[Daniel Moreira Yokoyama]

Cara... ter validações no domínio sem ter repetição na UI não existe, a menos que você crie fórmulas mirabolantes que só vão deixar seu domínio acoplado à view e nunca atenderão 100% dos casos.

Eu desencanei disto. Passei a entender que validação no client é uma issue de UX e deixe de lado este pensamento de que é "trabalho repetido".

Atenciosamente,

Daniel Moreira Yokoyama.

@dmyoko

http://twitter.com/dmyoko

 

Blogs:

Getting Sharper (C#, Arquitetura de Software e outras coisas mais)
http://gettingsharper.wordpress.com/

 

Eis o Cristo... e jaz o Cristão (Cristianismo sem Religiosidade)

http://eisocristo.wordpress.com

 

Stay Sharp!

[Daniel Moreira Yokoyama]

Felipe... se a classe tem uma dependência pra existir (por exemplo, um curso precisa pertencer a um módulo) então, sim... eu valido isso na construção.

Atenciosamente,

Daniel Moreira Yokoyama.

@dmyoko

http://twitter.com/dmyoko

 

Blogs:

Getting Sharper (C#, Arquitetura de Software e outras coisas mais)
http://gettingsharper.wordpress.com/

 

Eis o Cristo... e jaz o Cristão (Cristianismo sem Religiosidade)

http://eisocristo.wordpress.com

 

Stay Sharp!

[Winston Pacheco Junior]

Então até que nos entendemos?

Talvez eu tenha q aprender a me comunicar melhor, mas foi bem isso que eu quis dizer.

[Daniel Moreira Yokoyama]

João,

O que você está chamando de modelo anêmico?

Atenciosamente,

Daniel Moreira Yokoyama.

@dmyoko

http://twitter.com/dmyoko

 

Blogs:

Getting Sharper (C#, Arquitetura de Software e outras coisas mais)
http://gettingsharper.wordpress.com/

 

Eis o Cristo... e jaz o Cristão (Cristianismo sem Religiosidade)

http://eisocristo.wordpress.com

 

Stay Sharp!

Em 31 de julho de 2012 15:25, João Bateloche <jbate...@gmail.com> escreveu:

[Daniel Moreira Yokoyama]

Mas a minha resposta não tinha sido pra vc winston... foi pro Igor... foi ele que mencionou Validation Tier. Não vc.

Atenciosamente,

Daniel Moreira Yokoyama.

@dmyoko

http://twitter.com/dmyoko

 

Blogs:

Getting Sharper (C#, Arquitetura de Software e outras coisas mais)
http://gettingsharper.wordpress.com/

 

Eis o Cristo... e jaz o Cristão (Cristianismo sem Religiosidade)

http://eisocristo.wordpress.com

 

Stay Sharp!

[João Bateloche]

Sem comportamento, apenas mantem estado.

[Daniel Moreira Yokoyama]

Sim, amigo. Eu sei o que são objetos anêmicos.

Eu quis dizer em que parte desta thread você está apontando este modelo.

Objetos que não se persistem não são objetos anêmicos.

Objetos de domínio são objetos criados pra normalizar o domínio (incluindo validações). Este é o comportamento deles, o de normalizadores. Isto não é um modelo anêmico.

Atenciosamente,

Daniel Moreira Yokoyama.

@dmyoko

http://twitter.com/dmyoko

 

Blogs:

Getting Sharper (C#, Arquitetura de Software e outras coisas mais)
http://gettingsharper.wordpress.com/

 

Eis o Cristo... e jaz o Cristão (Cristianismo sem Religiosidade)

http://eisocristo.wordpress.com

 

Stay Sharp!

[João Bateloche]

No caso, o que eu apontei como modelo anêmico foi o exemplo dado no início, nas duas vezes em que o mesmo foi citado.

E também não acho que um objeto deva saber se persistir. No exemplo os objetos de domínio possuem apenas getters e setters, sem nenhum comportamento específico, e disse no começo da thread que o domínio tem que se validar, só que não pelo IsValid, mas sim no construtor e nos métodos que alteram o estado do mesmo.

[Daniel Moreira Yokoyama]

Sim. Entendo. Foi só pra me certificar que a gente não tava desalinhado mesmo.

Atenciosamente,

Daniel Moreira Yokoyama.

@dmyoko

http://twitter.com/dmyoko

 

Blogs:

Getting Sharper (C#, Arquitetura de Software e outras coisas mais)
http://gettingsharper.wordpress.com/

 

Eis o Cristo... e jaz o Cristão (Cristianismo sem Religiosidade)

http://eisocristo.wordpress.com

 

Stay Sharp!

[Victor Santos]

Olá,

Obrigado pela atenção a minha dúvida. Pelo que entendi vocês chegaram
a um certo concesso de que a classe de domínio deve saber se validar e
que isso pode ser feito no próprio construtor desta classe, certo?

Decidi que continuarei usando o Service Pattern com o intuito de
deixar o controller mais leve e que irei remover as validações desta
camada Service(como mostrado no artigo). Ainda estou na duvida se devo
realmente criar classes de ViewModel pensando que as validações
estejam nela, entendo a ViewModel como um agente para "patrocinar" as
Views, talvez seja necessário manter as validações com Data Annotation
dentro delas, não entendi a vantagem de se usar o Fluent Validation,
alguém pode clarear isso?

Quero evitar ao máximo duplicar códigos para validações, como ter que
escrever em JS e C# a
mesma validação. Por isso, deixarei as validações mais complexas para
o momento apos um POST no dominio -construtor-(ou seja sem ASYNC), o que
acham? 90% das validações com o DA+ jQuery.validation com ViewModel
irão pegar.

Estou desenvolvendo este projeto pessoal orientado a TDD e atento aos
princípios SOLID, posso considerar ele como um modelo RICO? Ou é
obrigatório o uso de DDD para se afirmar isso? Sempre tive esta
dúvida. Outra coisa, o que caracteriza modelos anêmicos ou ricos?

Grande abraço, estou aprendendo muito com vocês!


Em 31 de julho de 2012 17:23, Daniel Moreira Yokoyama

[João Bateloche]

Vitor, segue algumas considerações:

Obrigado pela atenção a minha dúvida. Pelo que entendi vocês chegaram a um certo concesso de que a classe de domínio deve saber se validar e que isso pode ser feito no próprio construtor desta classe, certo?

Correto, na verdade a classe de domínio deve garantir que está sempre em um estado válido.

Um exemplo bem simples de validação no construtor:

 

public sealed class Produto

{

    public String Nome { get; protected set; }

    public Decimal Valor { get; protected set; }

 

    public Produto(String nome, Decimal valor)

    {

        if (String.IsNullOrEmpty(nome))

            throw new ArgumentOutOfRangeException("nome", "O nome do produto não pode ser vazio");

 

        if (nome.Length > 50)

            throw new ArgumentOutOfRangeException("nome", "O nome do produto não pode exceder 50 caracteres");

 

        if (valor <= 0)

            throw new ArgumentOutOfRangeException("valor", "O valor do produto deve ser maior que 0");

    }

}

Decidi que continuarei usando o Service Pattern com o intuito de deixar o controller mais leve e que irei remover as validações desta camada Service(como mostrado no artigo). Ainda estou na duvida se devo realmente criar classes de ViewModel pensando que as validações estejam nela, entendo a ViewModel como um agente para "patrocinar" as Views, talvez seja necessário manter as validações com Data Annotation dentro delas, não entendi a vantagem de se usar o Fluent Validation, alguém pode clarear isso?

A ViewModel seria a representação da tela e pode sim conter os Data Annotation, nem sempre o formulário da apresentação é idêntico à classe de domínio, aí a grande vantagem da ViewModel.

Quanto ao Fluent Validation, não conheço, então não posso dar nenhuma opnião agora.

Quero evitar ao máximo duplicar códigos para validações, como ter que escrever em JS e C# a mesma validação. Por isso, deixarei as validações mais complexas para o momento apos um POST no dominio -construtor-(ou seja sem ASYNC), o que acham? 90% das validações com o DA+ jQuery.validation com ViewModel irão pegar.

É um trade off que que dependendo do seu cenário é válido, com os annotations você barrará a maior parte das requests inválidas.

Apenas tome o cuidado de criar uma exception específica para validação e captura-la na apresentação, assim você exibe mensagens amigáveis em vez de estourar a tela de erro para o usuário.

Estou desenvolvendo este projeto pessoal orientado a TDD e atento aos princípios SOLID, posso considerar ele como um modelo RICO? Ou é obrigatório o uso de DDD para se afirmar isso? Sempre tive esta dúvida. Outra coisa, o que caracteriza modelos anêmicos ou ricos?

Modelo rico ou anêmico não depende da utilização do DDD, a idéia é simples:

Modelo Rico apresenta comportamento, ou seja, métodos que representem seu comportamento real e as regras de negócio do seu sistema. (É fugir um pouquinho da idéia dos setters públicos e das classes com métodos CRUD).

Modelo Anêmico: Entidades não apresentam comportamento real apenas têm suas propriedades manipuladas por classes terceiras ou pela interface.

Aproveitando, as entidades não devem saber se persistir, isto deve ser responsabilidade de uma classe específica (normalmente um repositório).

Com exceção do padrão repositório, nada disso surgiu no DDD, então o mesmo não é requisito para chamar um modelo de “rico”. Alguns modelos podem ser ricos utilizando padrões como o Active Record (O Ruby on Rails é baseado neste padrão). 

Abraço.

[Victor Santos]

João,

Entendi perfeitamente suas observações. Claro e objetivo!

Assim que codificar as validações dos Dominios e ViewModels passo pra vocês analisarem. Estou pensando em criar validações com Fluent Validation( http://fluentvalidation.codeplex.com/ ) e utilizar elas para todos os pontos de validações, com o intuito de respeitar o DRY e  SPOF.

Veja um exemplo de como o Fluent Validation funciona para deixar as coisas mais claras: 

using FluentValidation; public class CustomerValidator: AbstractValidator<Customer> { public CustomerValidator() { RuleFor(customer => customer.Surname).NotEmpty(); RuleFor(customer => customer.Forename).NotEmpty().WithMessage("Please specify a first name"); RuleFor(customer => customer.Company).NotNull(); RuleFor(customer => customer.Discount).NotEqual(0).When(customer => customer.HasDiscount); RuleFor(customer => customer.Address).Length(20, 250); RuleFor(customer => customer.Postcode).Must(BeAValidPostcode).WithMessage("Please specify a valid postcode"); } private bool BeAValidPostcode(string postcode) { // custom postcode validating logic goes here } } Customer customer = new Customer(); CustomerValidator validator = new CustomerValidator(); ValidationResult results = validator.Validate(customer); bool validationSucceeded = results.IsValid; IList<ValidationFailure> failures = results.Errors;

Ou seja, tanto no meu construtor (objetos de domínio) e ViewModels estaria invocando este objeto de validação.

Abraços!

[Igor]

Vitor é exatamente assim que eu faço.

[Rafael Uchôa]

Igor,

 Como você tem a cobertura de testes unitários utilizando o Fluent Validation usando os validators por construtor ?

Em 1 de agosto de 2012 07:54, Igor <oro...@gmail.com> escreveu:

Vitor é exatamente assim que eu faço.

[Fernando Mondo]

A ViewModel se torna necessária uma vez que o Model Bind do Mvc usa reflection para instanciar as classes (e obriga um construtor sem parâmetros) passando por cima de suas validações.

o FluentValidator facilita pois você pode validar tudo da ViewModel de uma vez, com acesso a banco e validações customizadas muito mais fácil que os DataAnnotation.

[Igor]

Eu não testo os meus viewmodels nem os meus dtos.

A minha camada de apresentação não conhece os meus objetos de dominio. Eu "converto" (ou transformo) o meu objeto de dominio para dto e o dto (ou viewModel) vai para a camada de aplicação.

Então o Fluent Validation fica nos dtos ou nos viewmodels e não nas entidades. O que me obriga a validar no dois tanto na camada de dominio como na interface com o usuario. Mas as válidações são diferentes.

Eu testo o dominio normalmente. Tenho um projeto de teste para o dominio, um para a camada de aplicação e assim por diante. Eu não testo a UI.


public class Ficha
    {
        public Ficha(string nome, string email)
        {
            if (string.IsNullOrWhiteSpace(nome))
                throw new Exception("Obrigatório o nome");

            if (string.IsNullOrWhiteSpace(email))
                throw new Exception("Obrigatório o email");
        }

        public int IdFicha { get; private set; }
        public string Nome { get; private set; }
        public string Email { get; private set; }
    }

    public class FichaViewModel
    {
        public int IdFicha { get; set; }
        public string Nome { get; set; }
        public string Email { get; set; }
        public string ConfirmarEmail { get; set; }
    }

    public class FichaValidator : AbstractValidator<Ficha>
    {
        public FichaValidator()
        {
            RuleFor(x => x.Email).NotEmpty()
                 .WithMessage(Mensagens.Preenchimento_Obrigatorio)
                 .WithName(Campos.ConfirmacaoEmail)
                 .EmailAddress().WithMessage(Mensagens.Email_Valido)
                 .WithName(Campos.Email);

            RuleFor(x => x.ConfirmacaoEmail).NotEmpty().WithMessage(Mensagens.Preenchimento_Obrigatorio)
                .Equal(x => x.Email).WithMessage(Mensagens.Emails_Iguais)
                .WithName(Campos.ConfirmacaoEmail);
        }
    }

    public class FichaTest
    {
        [TestMethod]
        public void TestarEntradaViaConstrutor()
        {
            // Teste Aqui.
        }
    }

[Fernando Mondo]

Não faz sentido isso, a classe Ficha não precisa ser validada, já que ela nunca estará em um estado inválido (graças aos throw Exception).

Quem tem que ser validado é a ViewModel, para que quando eu criar a entidade do dominio com os dados dela não receber nenhum  Exception.

        }
    }

[Igor]

Fernando, pra isso eu uso o Fluent Validation.

Esse codigo foi um exemplo rapido e simples que eu criei na hora. Claro que teria as Roles para NotEmpty para "nome" também.

Em fim. No Model Bind eu garanto que a minha ViewModel passou pelas validações do Fluent Validation e está pronta para ser transformar em uma entidade (a grosso modo dizendo).

[Daniel Moreira Yokoyama]

Eu não gosto de validação na view model. Eu gosto de validar na UI pra melhorar a experiência (javascript) e evitar roudtrips desnecessários... mas no serversite, já que o domínio se valida, eu acho perda de tempo validar a viewmodel.

Atenciosamente,

Daniel Moreira Yokoyama.

@dmyoko

http://twitter.com/dmyoko

 

Blogs:

Getting Sharper (C#, Arquitetura de Software e outras coisas mais)
http://gettingsharper.wordpress.com/

 

Eis o Cristo... e jaz o Cristão (Cristianismo sem Religiosidade)

http://eisocristo.wordpress.com

 

Stay Sharp!

[Fernando Mondo]

boiei...

você disse que não validava a viwemodel e ainda colocou  AbstractValidator<Ficha>.

Eu já faço o contrario:

Valido tudo na Viewmodel (mesmo que isso cause duplicação)  então faria  AbstractValidator<FichaViewmodel>. 

Em 1 de agosto de 2012 10:52, Igor <oro...@gmail.com> escreveu:

[Igor]

Fernando desculpa, na correria eu coloquei o nome errado é AbstractValidation<FichaViewModel>.

@dmyoko Não sei se você já trabalhou com o Fluent Validation, mas ele valida tanto no Ui (jquery.validation) como no server-side.

Nisso ele é melhor e mais flexivel que o DataAnnotation.
Confesso que na pressa me expressei muito mal.

Eu valido a viewModel com o Fluent Validation.
E válido a entrada de dados no construtor da entidade.

[Renato Cantarino]

Validações do tipo ServerSide, não são praticados aqui na empresa a seculos....

Todas as validações são feitas na UI, como o daniel colocou!

--

Você recebeu esta mensagem porque faz parte do grupo .Net Architects hospedado no Google Groups.
Para postar envie uma mensagem para dotnetar...@googlegroups.com
Para sair do grupo envie uma mensagem para dotnetarchitec...@googlegroups.com
Para mais opções visite o grupo em http://groups.google.com/group/dotnetarchitects?hl=pt-br

--

Att,

Renato Cantarino

[Fernando Mondo]

Como é que vocês lidam com validações com acesso a banco?

uma requisição a mais antes de dar o submit na viewmodel?

[João Bateloche]

Renato, você tem que validar no server-side também, o que estamos discutindo é como validar.

Se você faz validação apenas no cliente, qualquer pessoa que saiba usar o firebug consegue burlar.

Em 1 de agosto de 2012 11:16, Renato Cantarino <renato.c...@gmail.com> escreveu:

[Fernando Mondo]

esta é minha opinão também...

[João Bateloche]

Fernando, não entendi.

Com relação à integridade e tipagem no banco?
Se for isso, o seu modelo deve garantir que é válido. E não vejo muito sentido em uma requisição somente para validar, até por que além da questão de performance, você ainda estará sujeito a tampering.

Se não é possível fazer a validação de alguns pontos no cliente, efetue o submit da página e deixe que o servidor valide.

[Daniel Moreira Yokoyama]

Eu faço a validação no server side, mas uso o domínio pra isto. O que eu não faço é validação na viewmodel (que é apenas uma viewmodel, só serve pra capturar o que vem da view e disparar algo no domínio - que garante a validação, tanto do input de dados, quanto a restrições do domínio).

No client, eu uso javascript mesmo... não misturo com frameworks serversite, primeiro pq não preciso, segundo pq normalmente estes frameworks aumentam a rigidez (não atentem casos específicos e você se vê obrigado a extendê-los pra fazer o que você precisa que façam).

Atenciosamente,

Daniel Moreira Yokoyama.

@dmyoko

http://twitter.com/dmyoko

 

Blogs:

Getting Sharper (C#, Arquitetura de Software e outras coisas mais)
http://gettingsharper.wordpress.com/

 

Eis o Cristo... e jaz o Cristão (Cristianismo sem Religiosidade)

http://eisocristo.wordpress.com

 

Stay Sharp!

[Fernando Mondo]

então você adiciona o erro no ModelState na mão? com um ModelState wrapper?

tipo 

if (Cliente == null)

modelState.AddError("Cpf", "Cpf Inválido"); 

[Daniel Moreira Yokoyama]

Sim, baseado na exception que recebo.

Vale a pena dizer que já faz um tempinho que eu não tenho usado mais renderização de view no server... estou voltando a fazer isto agora. Até então eu não estava mais precisando usar o modelState... eu simplesmente retornava uma mensagem de erro no http. (409, normalmente).

Atenciosamente,

Daniel Moreira Yokoyama.

@dmyoko

http://twitter.com/dmyoko

 

Blogs:

Getting Sharper (C#, Arquitetura de Software e outras coisas mais)
http://gettingsharper.wordpress.com/

 

Eis o Cristo... e jaz o Cristão (Cristianismo sem Religiosidade)

http://eisocristo.wordpress.com

 

Stay Sharp!

[Rafael Uchôa]

É como eu imaginei. Você perde o índice de cobertura de código, não que se deva confiar totalmente nele, mas é uma perda. Eu gostei do Fluent Validation, só estou com esse problema.

[Fernando Mondo]

eu tenho varios testes com fluentValidator, com DataAnnotation é que não tem como testar...

o FluenteValidator tem metodos de extensão para testes como:

_validator.ShouldHaveValidationErrorFor(x => x.IdProduto, produto);

_validator.ShouldHaveChildValidator(x => x.Slider, typeof(SliderValidator));

e ainda você pode criar testes para validar uma determinada ViewModel

var result = _validator.validate(new ProdutoViewModel(){});

Assert.isFalse(result.isValid());     

[Rafael Uchôa]

Fernando,

 Como testar, existe várias maneiras, mas a cobertura de testes unitários sempre lhe dará 100%, pois tudo está no construtor.

[Ygor Thomaz]

Olá,

Apenas com o intuito de fazer uma pequena contribuição, existem formas
de testar mesmo utilizando DataAnnotations.

Analisem este código, por exemplo:
http://gcbyjm.blogspot.com.br/2011/02/how-to-unit-test-dataannotations.html

Existem outras formas, eu já utilizei esta acima e funcionou. Fiz umas
pequenas adaptações para o código ficar mais "limpo" nos meus testes e
apenas isso.

Vale lembrar que eu peguei o projeto andando e já utilizavam Data Annotations.

Existem alguns detalhes negativos sobre a utilização do Fluent
Validation em client-side(analisem).

Source: http://fluentvalidation.codeplex.com/wikipage?title=mvc&referringTitle=Documentation

"Note that FluentValidation will also work with ASP.NET MVC's
client-side validation, but not all rules are supported. For example,
any rules defined using a condition (with When/Unless), custom
validators, or calls to Must will not run on the client side. The
following validators are supported on the client:

*NotNull/NotEmpty
*Matches (regex)
*InclusiveBetween (range)
*CreditCard
*Email
*EqualTo (cross-property equality comparison)
*Length"

Sou a favor da criação das ViewModels, só para registrar. Classes
Domínio e ViewModel tem objetivos diferenciados, mesmo sendo
parecidos.

Best regards,

--
Ygor Thomaz
Website: http://www.ygorthomaz.com/ | Twitter: @ygorthomaz
"With Great Power Comes Great Responsibility." Uncle Ben, Spiderman

Em 1 de agosto de 2012 13:39, Fernando Mondo
<fernand...@gmail.com> escreveu:

[Igor]

Sim, Ygor, o tem validações do Fluent que não funciona client side, mas ele valida no Model Bind.
Então é só chamadar o ModelState.IsValid() se valida blz, se não retorna o model para a view e o Fluent se vira com a mensagem.