Disponível livro gratuito sobre Demoiselle Framework

Ótimo livro!!

+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?

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?

tnaires:

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?

Pois é, nesse aspecto o framework já está atrasado.
Sem falar que o livro fomenta a utilização do modelo anêmico.

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.

opinião pessoal

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.

Eu adoro o nome deste framework. Muito bom. http://pt.wikipedia.org/wiki/Santos-Dumont_Demoiselle

Não conheço o framework, mas se tem sensibilidade boa para escolher um nome (e portanto, bom gosto estético), má coisa não deve ser.

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.

Falta de cérebro.

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.

Com certeza que ele ta dentro. kakakakakaka

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

Se eu entendi a pergunta, só há duas alternativas: interface ou sub-classe.

Ué, então pra Pojo pelo menos eles fizeram o certo. Ou estou falando besteira?

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.

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.

Tenho a mesma opinião do esmiralha.

public interface Entity {
    int getId();
    void setId(int i);
}

public interface Entity<T> {
    T getId();
    void setId(T t);
}

public interface Entity<?> {

}

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.

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.

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.

interface DAO<T extends Serializable> { void gravar(T t); }

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:

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”.