Eu tenho a preocupação de, sempre que possivel, nao deixar um objeto ser instanciado em estado inconsistente. Ou seja, procuro passar no construtor, tudo que o objeto necessita para existir com integridade, garantindo assim que ele nao vai ser persistido num estado invalido.
O mesmo serve para uma mudança de estado, pra mudar do estado A para o B, é necessário que ele realmente esteja no A e que tudo que for preciso pra ele chegar no B seja feito dentro de uma unica operacao, ou ele nao sai do A.
Até aí tudo bem, nada de novo.
Em frameworks como grails e rails eu posso por validadores na propria entidade, sem problemas, mas ainda assim ha a mudanca de estados. Em java, em frameworks como VRaptor, ou até mesmo JSF, quando a propria entidade eh utilizada na view eu necessariamente preciso por metodos sets, deixando em alguns momentos meus objetos em estado invalido.
Depois tenho que espalhar validadores, validar antes de salvar, validar ao receber os valores da view, validar aqui e validar ali, e numa dessas escapa algo que nao escaparia da outra forma e vai meu objeto ser gravado de forma insconsistente.
A minha duvida é: estou sendo muito purista? Eu estou usando essas ferramentas de forma errada e há uma forma que eu nao conheco de nao usar sets desnecessarios? Essa nova forma de expor os objetos na view diretamente nao está quebrando o principio basico do encapsulamento do qual tanto ouvimos falar quando estudamos os principios basicos OO?
Na minha opnião acredito que não.
PARTICULARMENTE gosto de fazer a validação dos dados em uma camada reservada para isso.
Por exemplo sempre que salvo um objeto, antes faço a validação e depois o comando para salvar.
Se é a melhor prática ou não, não posso dizer, porém é a forma que gosto de trabalhar.
[quote=leonardoMachado]Na minha opnião acredito que não.
PARTICULARMENTE gosto de fazer a validação dos dados em uma camada reservada para isso.
Por exemplo sempre que salvo um objeto, antes faço a validação e depois o comando para salvar.
Se é a melhor prática ou não, não posso dizer, porém é a forma que gosto de trabalhar.[/quote]
Pois é, essa é uma prática comum hoje. Mas será que isso não vai contra a idéia trazida pelo TDD, ou pelo menos difundida pelo TDD, de que ao inves de corrermos atras do bugs, nao devemos deixar que eles sejam introduzidos.
Nao estou dizendo que nao eh possivel fazer TDD com o modelo de validadores, estou me questionando, se numa escala menor não é exatamente isso que estamos fazendo quando “introduzimos um bug” e depois ficamos “procurando ele” com os validadores?
Alem disso, será que fazer essa validação em outra camada, nao estamos tirando as regras de negocio de onde elas deveriam estar, que é nas entidades do dominio?
Não conheço muito sobre TDD, porém o que diz. Acredito que isso possa até facilitar a encontrar eles pelo seguinte:
Supondo que o bug esteja ocorrendo por algum problema de validação vc certamente irá procurar na camada de validação.
E também por uma questão semântica a camada de modelo é onde são suas entidades do seu sistema, a camada de validação vc sabe que só serve para validar, controlers para fazer o controle da aplicação e por aí vai.
E também vai da empresa, e de caso a caso.
Eu particularmente gosto de separar as coisas.
[quote=YvGa]e numa dessas escapa algo que nao escaparia da outra forma e vai meu objeto ser gravado de forma insconsistente.
[/quote]
Penso que ter um objeto em estado inconsistente em algum momento, não é necessariamente BUG. O que deve-se garantir é que não sejam realizadas operações com o objeto em estado inconsistente.
E é nisto que o TDD é perfeito. Você escreve testes para cada operação e falha caso o objeto não esteja ok. Assim, TDD garante que algo não vai escapar numa dessas…
[quote=YvGa]
Mas pra mim é muito estranho por sets onde teoricamente eu nao precisaria. Talvez seja apenas preciosismo meu.[/quote]
AH, aí sou eu que concordo com você. Também não faria isso. No JPA, mapeio os atributos direto, sem criar getters e setters desnecessários. No JSF, você precisou criar getters em que situação?
Nos nossos sistemas, utilizamos validadores dos frameworks prá fazer “validações prévias” afim de agilizar as respostas para o usuário. Mas todas as regras de negócio estão implementadas dentro dos objetos de domínio. As regras serão respeitadas idependentes do framework de UI.
[quote=luizSC][quote=YvGa]
Mas pra mim é muito estranho por sets onde teoricamente eu nao precisaria. Talvez seja apenas preciosismo meu.[/quote]
AH, aí sou eu que concordo com você. Também não faria isso. No JPA, mapeio os atributos direto, sem criar getters e setters desnecessários. No JSF, você precisou criar getters em que situação?
Nos nossos sistemas, utilizamos validadores dos frameworks prá fazer “validações prévias” afim de agilizar as respostas para o usuário. Mas todas as regras de negócio estão implementadas dentro dos objetos de domínio. As regras serão respeitadas idependentes do framework de UI.
Abraços[/quote]
Quando vc expoe suas entidades na view, como por exemplo um #{managedBean.objeto.metodo}.
Sim, resolve, mas não é o que tem sido utilizado, o que esta sendo feito é a exposicao do objeto na view, e depois as validacoes.
A minha duvida é sobre esse conceito que vem sendo utilizado e cada vez mais adotado, nao necessariamente com a implementacao disso. Eu posso evitar, evidentemente, de expor atraves dos sets. Mas a pratica que esta tomando conta é expor.
[quote=YvGa]Sim, resolve, mas não é o que tem sido utilizado, o que esta sendo feito é a exposicao do objeto na view, e depois as validacoes.
A minha duvida é sobre esse conceito que vem sendo utilizado e cada vez mais adotado, nao necessariamente com a implementacao disso. Eu posso evitar, evidentemente, de expor atraves dos sets. Mas a pratica que esta tomando conta é expor.[/quote]
Concordo com você. Esta preocupação não é preciosismo. Sets indiscriminandos detonam o encapsulamento.