Validação na camada de negócios

Estou cansado de ver frameworks de validação para web, mas alguém conhece um framework de validação para camada de negócio?

.Java

Spring

O que você quer validar na camada de negócios?

Um objeto deve ser responsável por sua validação.

Dá uma olhada:

http://www.fragmental.com.br/arquivos/contratos-nulos.pdf

[]s

Não concordo.

Pra algumas situações sim, mas muitas vezes o que determina se um objeto é válido é o contexto onde ele está inserido. Objetos que trazem dentro de si definições do contexto onde estão inseridos são menos reusáveis. Na classe Ponto do artigo, por exemplo, se você tem agora um domínio onde o ponto está inserido (espaço cartesiano?) maior a sua classe ponto simplesmente não serve mais. “Ah mas as modificações são simples” mas a classe não é a mesma.

Objetos modelam o mundo real e no mundo real algumas coisas são válidas dependendo do momento, da situação.

.Java

Olá,

Cada objeto é simr esponsável por manter sua invariante, isso é o princípio básico de Design by Contract e teoria de OOP.

Um objeto não é válido de acordo com o contexto, o contexto é que é válido de acordo com os objetos que o compoem. Um contexto inválido não torna um objeto que faz parte deste inválido, mas um objeto inválido pode tornar seu contexto inválido.

Se você pensar que seu ponto pode ser utilizado num escopo mair, de 3 ou quatro dimensoes, que seu emprestimo pode ser usado em outro programa, que sua classe de conexão pode ser reutilizada… você está praticando overengineering, se preparando apra uma situação que “talvez” aconteça.

Não crie o que você não precisa hoje, crie uma arquitetura flexível para adaptá-la amanhã com facilidade. YAGN.

[quote=“pcalcado”]Olá,

Cada objeto é simr esponsável por manter sua invariante, isso é o princípio básico de Design by Contract e teoria de OOP.

[/quote]

Nunca vi isso em teoria de OOP.

Seguindo o princípio básico da teoria de OOP: tudo é objeto.
Então se imagine como um objeto. Será que não há métodos (atitudes) ou atributos seus (roupas) que não são válidos em um contexto mas são válidos em outros? Espero que você entenda que sim ou isso pode levar você a cantar pagode com um vestido de noiva em um funeral.

3 ou quatro dimensões? Eu quis dizer coisas mais simples, tipo um espaço cartesiano de (1.000.000, 1.000.000) ou com possibilidades de valores negativos. O mais simples que se pode pensar de um ponto.

[quote=“pcalcado”]
Não crie o que você não precisa hoje, crie uma arquitetura flexível para adaptá-la amanhã com facilidade.[/quote]

E esqueça reusabilidade, outro dos princípios básicos de OOP (e o motivo pelo qual tantas empresas resolveram investir em OO).

Então você precisa ler mais. Algumas sugestões:

http://www.temporeal.com.br/produtos.php?id=166700
http://www.temporeal.com.br/produtos.php?id=167402
http://www.temporeal.com.br/produtos.php?id=154171
http://www.temporeal.com.br/produtos.php?id=168948
http://www.temporeal.com.br/produtos.php?id=165474
http://www.temporeal.com.br/produtos.php?id=158318
http://www.umlcomponents.com/



Pelo menos o Meyer.

Atenção ao que eu disse: não é porque a sua pessoa está vestida de noiva num lugar impróprio que o vestido é inválido. Nem o fato de você se vestir de noiva num funeral invalida o estado do caixão ou do defunto (ele levanta assustado para saber o que acontece por acaso?).

Este era o domínio da aplicação?

Se não for (e não era, já que eu escrevi a aplicação e sei), tanto faz se são os pontos do bordado do seu vestido de noiva ou apenas mais 1000 possibilidades combinadas, é outro domínio e a capacidade de adaptaçãod epende da flexibilidade do software modelado.

[quote=“dotjavaguy”]
E esqueça reusabilidade, outro dos princípios básicos de OOP (e o motivo pelo qual tantas empresas resolveram investir em OO).[/quote]

Desculpe, mas você está torcendo minhas palavras.

Qual parte do “Não crie o que você não precisa hoje, crie uma arquitetura flexível para adaptá-la amanhã com facilidade” você não entendeu?

Reusabilidade não é criar arquiteturas genéricas nemc riar mais do que você precisa.