Disponível livro gratuito sobre Demoiselle Framework

JavaEvangelist Membro desde: 19/07/2006 09:04:42 Mensagens: 402 Offline

Eu não sei, Marcos. Eu teria que dar mais atenção ao framework antes de poder dar uma opinião. Mas, de uma maneira geral, considero invasivos os frameworks que exigem que os objetos de negócio implementem uma interface ou estendam uma classe. Idealmente, quanto menos invasivo, melhor, porém há geralmente um trade-off na facilidade de uso do framework.

GUJ Expert Membro desde: 20/02/2008 12:32:59 Mensagens: 3371 Offline

esmiralha wrote:Eu não sei, Marcos. Eu teria que dar mais atenção ao framework antes de poder dar uma opinião. Mas, de uma maneira geral, considero invasivos os frameworks que exigem que os objetos de negócio implementem uma interface ou estendam uma classe. Idealmente, quanto menos invasivo, melhor, porém há geralmente um trade-off na facilidade de uso do framework.

Acho que entendi o problema. Pelo menos em Pojos, geralmente o pessoal implementa uma interface pra identificar o objeto como sendo um pojo ou pra acessar métodos em comum na arquitetura adotada. O problema é o framework exigir esse comportamento pra uma interface específica, certo?

Acredito que o motivo é porque o Demoiselle possui uma arquitetura definida, que é a adotada pelo governo. É uma tentativa de padronizar uma arquitetura mínima entre os vários programas dos vários orgaos estatais.

Se isso é bom ou ruim, não tenho opinião formada ainda.

JavaEvangelist Membro desde: 19/07/2006 09:04:42 Mensagens: 402 Offline

Pode ser, Marcos.

Tem um padrão chamado Abstract Class que é a idéia de você ter uma classe base abstrata para os principais conceitos da sua arquitetura. Se você tem Filtros, crie um BaseFilter, se tem DAOs crie um BaseDAO, a mesma coisa com Entidades... etc. Eu acho que quando o framework exige que você estenda uma classe dele, o padrão Base Class se torna ainda mais útil, ajudando de certa forma a isolar a dependência do framework na classe base.

This message was edited 2 times. Last update was at 12/11/2010 10:50:23

Tenho a mesma opinião do esmiralha.

Já vi desenvolvedores usarem interface para as entidades do modelo de domínio da seguinte forma:

Essa forma força todas as entidades a possuírem um id do tipo inteiro.
Então as coisas podem ficar mais flexíveis:

Isso corrige o problema do tipo, porém o nome do atributo que armazena o identificador tem que ser obrigatoriamente "id", e isso pode ser ruim para a linguagem utilizada no domínio. E se eu tiver uma entidade Pessoa cujo nome do identificador seja "cpf"? E se tiver uma classe Usuario com identificador "login"?

Para evitar esse problema, podemos tirar os métodos getId() e setId() da interface:

Mas, sinceramente, qual o ganho que teríamos aqui?

Resumindo, essa prática é invasiva porque força o desenvolvedor a adotar certas convenções que talvez não fossem interessantes para todas as situações.

GUJ Expert Membro desde: 20/02/2008 12:32:59 Mensagens: 3371 Offline

tnaires wrote:
Mas, sinceramente, qual o ganho que teríamos aqui?

Teríamos o ganho de poder criar um método

Vejo muita arquitetura fazer algo do tipo, muitas vezes pra um DAO generico, por exemplo.
Por isso minha dúvida se o problema é o uso ou a vinculação disso a um framework.

This message was edited 2 times. Last update was at 12/11/2010 10:53:10

marcosalex wrote:Teríamos o ganho de poder criar um método

public Boolean gravar(Entity o) { ... }

Vejo muita arquitetura fazer algo do tipo, muitas vezes pra um DAO generico, por exemplo.
Por isso minha dúvida se o problema é o uso ou a vinculação disso a um framework.

Eu ainda acharia melhor simplesmente parametrizar o DAO do que forçar todas as minhas entidades a implementar Entity:

JavaEvangelist Membro desde: 19/07/2006 09:04:42 Mensagens: 402 Offline

Marcos,

se a interface IPojo é de uma biblioteca de terceiros que dá suporte a persistência, me parece ruim que um detalhe de persistência invada o domínio. O melhor seria acoplar isso a um DAO (que pode ser visto como a faceta de persistência de um objeto de domínio).

O Hibernate resolve isso através de um mapeamento externalizado em XML. O objeto de domínio desconhece Hibernate, nem sabe que está sendo persisitido (idealmente).

O ActiveRecord do Rails por sua vez exige a extensão de uma classe. No caso do Rails, meu entendimento é que o mapeamento OR é "ingênuo", no sentido de assumir que o modelo relacional e o modelo de objetos são extremamente similares.

O Hibernate possui maior flexibilidade para mapear seus objetos ao modelo relacional. Por outro lado, Rails é mais fácil de usar. Esse é o trade-off, NMHO.

marcosalex wrote:Agora fiquei com uma dúvida: qual a alternativa sem criar interface pra identificar usando Generics que a minha classe é um Pojo?

Opa,

Trabalho neste projeto, inicialmente IPojo era utilizado como uma marcação mesmo... realmente, tinha pouca função. Na versão 2.0 esta interface deixa de existir, assim como outras, dando lugar a marcações com anotações. No caso do IPojo, como usamos jpa... usa-se a própria @Entity;

Mas como sua pergunta é em relação a generics... simplesmente estamos passando Object quando esperamos que a classe possua um "Pojo".

Notícias, artigos e o maior fórum brasileiro sobre Java