O livro “Introdução ao Demoiselle Framework: uma abordagem comparativa de aplicações Web em Java orientada ao reuso” está disponível para download no portal do Demoiselle Framework. Basta entrar no menu Documentação->Livro e baixar.
O livro é destinado a iniciantes em Java Web. que queiram começar a estudar o Demoiselle, mas não tem base nas tecnologias que ele utiliza. Assim, ele parte de uma aplicação Web sem frameworks até a abstração feita pelo Demoiselle, mostrando o que está acontecendo (ou o que está sendo oculto da preocupação do programador).
+1 framework para a lista de frameworks…
A pergunta é: vão atualizar o core dele sempre que sair uma nova versão dos fremeworks que ele está encapsulando?
[quote=Eduardo Bregaida]+1 framework para a lista de frameworks…
A pergunta é: vão atualizar o core dele sempre que sair uma nova versão dos fremeworks que ele está encapsulando?[/quote]
Pois é, nesse aspecto o framework já está atrasado.
Sem falar que o livro fomenta a utilização do modelo anêmico.
[quote=tnaires][quote=Eduardo Bregaida]+1 framework para a lista de frameworks…
A pergunta é: vão atualizar o core dele sempre que sair uma nova versão dos fremeworks que ele está encapsulando?[/quote]
Pois é, nesse aspecto o framework já está atrasado.
Sem falar que o livro fomenta a utilização do modelo anêmico.[/quote]
já vi aqui no forum discussões sobre este framework, quem defendia ele era o pessoal que estava desenvolvendo o mesmo…
eu particularmente não gostei…achei os exemplos muito complexos para apenas um simples CRUD, porêm tem o lado que o governo esta padronizando o desenvolvimento deles não faz de qualquer jeito.
Achei o modelo razoável.
Dá pra ficar no mesmo framework quando sair atualizações do que ele é usado, pelo menos até certo nível.
Independente das vantagens e desvantagens, é interessante pro governo uma padronização dos seus softwares, pra permitir aproveitamento de código e produtividade, coisa que está em falta no governo.
Meu antigo gerente deve trabalhar no projeto. hehehehe
Bom, sem analisar a arquitetura, não dá pra falar, mas na minha arquitetura os Pojos implementam uma interface comum que uso no Generics de várias outras funções.
Meu antigo gerente deve trabalhar no projeto. hehehehe
Bom, sem analisar a arquitetura, não dá pra falar, mas na minha arquitetura os Pojos implementam uma interface comum que uso no Generics de várias outras funções.[/quote]
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.
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.
Já vi desenvolvedores usarem interface para as entidades do modelo de domínio da seguinte forma:
public interface Entity {
int getId();
void setId(int i);
}
Essa forma força todas as entidades a possuírem um id do tipo inteiro.
Então as coisas podem ficar mais flexíveis:
public interface Entity<T> {
T getId();
void setId(T t);
}
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:
[code]public interface Entity<?> {
}[/code]
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.
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.
[quote=marcosalex]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. [/quote]
Eu ainda acharia melhor simplesmente parametrizar o DAO do que forçar todas as minhas entidades a implementar Entity:
