Em simpósio a ser realizado no auditório da Regional Curitiba do Serpro, em 15 de abril de 2009, a equipe CETEC/CTCTA apresentará o Demoiselle Framework, a plataforma de desenvolvimento em Java construída para ser o padrão dos sistemas do governo federal, e que será distribuída como software livre e mantida em comunidade.
A abertura do evento e a apresentação do Demoiselle serão transmitidos para todo Brasil por vídeo streaming, através do link abaixo, a partir das 10h30min.
Convido os que estiverem em Curitiba na data a participarem pessoalmente do evento. O Serpro fica na rua Carlos Pioli, 133, no bairro Bom Retiro, ao lado do Hipermercado Condor e da Celepar.
Bacana a notícia !
Eu não o conhecia, e achei interessante. Vi diversas discuções em relação a isso, uns contra outros a favor. Na minha opinião é uma boa idéia, resta saber se o framework é bom.
Dei uma olhada no site e olhei a documentação. Me pareceu boa, mas irei dar uma lida com mais calma e tentar fazer alguns coisa com ele. Quem tiver interessado segue o link abaixo.
Bem, fico esperando para ver o código.
Mas, olhando para a documentação, vi que existem várias interfaces para controle de transação e de persistência de forma genérica. Me pergunto se é vantajoso atualmente criar este tipo de coisa uma vez que temos o JPA aí, que é perfeitamente implementado pelo mesmo hibernate que é usado de forma tão extensiva no Demoiselle. Por que não o JPA?
Por que o framework não foi desenvolvido levando em consideração as convenções de código recomendadas pela Sun para a linguagem Java? Exemplo: interfaces começando com I.
O framework adota a tão comentada - e depreciada - arquitetura BOLOVO, com estado mantido nos beans e regras de negócio mantidas nos objetos que implementam a interface IBusinessController.
As especificações recomendadas para o ambiente de desenvolvimento indicam a utilização de versões antigas dos softwares envolvidos. Por exemplo, é recomendada a utilização do Eclipse Europa, com o Ganymede já existindo há quase um ano e às vésperas do lançamento do Galileo. Será que a equipe responsável adotou alguma estratégia para abraçar a evolução das versões dos softwares e bibliotecas - ou vão manter tudo engessado?
Todas as classes de modelo precisam implementar a interface IPojo? Isso não é ruim?
O documento disponível no site dá a entender que o mecanismo de IoC foi implementado do zero utilizando AspectJ. Por que essa decisão foi tomada? Por que não foi utilizada uma solução como o Spring?
Por que o framework não foi desenvolvido levando em consideração as convenções de código recomendadas pela Sun para a linguagem Java? Exemplo: interfaces começando com I.
O framework adota a tão comentada - e depreciada - arquitetura BOLOVO, com estado mantido nos beans e regras de negócio mantidas nos objetos que implementam a interface IBusinessController.
As especificações recomendadas para o ambiente de desenvolvimento indicam a utilização de versões antigas dos softwares envolvidos. Por exemplo, é recomendada a utilização do Eclipse Europa, com o Ganymede já existindo há quase um ano e às vésperas do lançamento do Galileo. Será que a equipe responsável adotou alguma estratégia para abraçar a evolução das versões dos softwares e bibliotecas - ou vão manter tudo engessado?
Todas as classes de modelo precisam implementar a interface IPojo? Isso não é ruim?
O documento disponível no site dá a entender que o mecanismo de IoC foi implementado do zero utilizando AspectJ. Por que essa decisão foi tomada? Por que não foi utilizada uma solução como o Spring?[/quote]
Eu ainda não li a documentação, mas pretendo ler o mais rápido possivel.
Sobre a primeira e a terceira questão, não vejo tanto problema em começar com I ou se usar o eclipse Europa ou o Ganymede. Como o próprio nome diz, recomendação, não obrigação. Se bem que seria uma boa idéia usar as recomendações da Sun, mas a IDE, tanto faz.
A questão dois eu desconheço e não tenho como dar minha opinião.
A questão 4, se for isso mesmo, fica o meu questionamento também.
A questão 5, eu posso imaginar o porque. Como dito eles não querem ficar dependendo de nada e por isso mesmo implementaram um container de IoC. Na minha opnião, foi perda de tempo, mas fazer o que.
As recomendações de código não são tão importantes, o importante é ter um padrão, seja qual for. Ponto para o framework. Porém, quanto às versões dos softwares, é importante atualizá-los sim, pois as novas versões trazem correções de bugs, atualizações de segurança e novas funcionalidades que podem ser importantes. Além disso, não me refiro apenas à IDE. Se atualizarem o Hibernate, por exemplo, ou qualquer outra biblioteca da qual o framework dependa? Há um plano para abraçar a nova versão?
EDIT: como bem citou o Maurício Linhares nesse post, “(…) esse tipo de ferramenta padrão é feita exatamente pra que não haja qualquer tipo de evolução”
Os documentos disponíveis aqui são bastante claros em relação à arquitetura. A existência da interface IBusinessController é uma evidência forte desse fato.
Antes de mais nada. quero deixar claro que este post expressa apenas a minha opinião.
Eu não adotaria o Demoiselle, pois ainda que concordasse com seu desenvolvimento, a arquitetura atual já comentada é muito engessada e ignora as correntes atuais de desenvolvimento. Mas um dia pode ser que eu trabalhe em um lugar que o utilize, então sem dúvida é importante conhecê-lo.
Mas o Demoiselle não é nada diferente dos frameworks corporativos próprios que já vi por aí, tanto em Java quanto em .NET. Parece até uma febre.
Bem, eu sempre odiei essa babaquice, er, quer dizer, maneira de nomear interfaces com o prefixo I: IQualquerCoisa, IAquiloAli, IPizza…
Mas, IPojo é triste. Pojo é, por definição um objeto que não é obrigado a herdar nenhuma classe de nenhum framework e nem implementar nenhuma interface de nenhum framework. Ao se criar uma interface IPojo no framework, e por qualquer motivo forçar qualquer classe a implementá-la, ela deixa de ser Pojo.
Gosto muito de ver esse movimento da galera criando novos frameworks etc, etc, etc … isso estimula, no caso, quem esta desenvolvendo a pensar de forma orientada e quem esta começando pode ter tbm um idéia de como fazer algo mais profissional … sei la … mais me lembro tbm que a tempos atras, tínhamos o framework ATENA, que tbm foi desenvolvido por algum órgão publico … que nao tinha nenhum IoC container próprio … maassss, foi criado para mesmo propósito, acredito …
E eu estava aqui pensando … ja que o Antena estava la … pq não melhorar o que ja existe … sei lá … mais fica a pergunta … não seria desperdício de tempo reinventar algo que ja existe ? temos tbm frameworks como o Click, NeoFramework … todos … acredito que criados para minimizar o tempo de desenvolvimento … acredito.
Portanto, como disse anteriormente, acho muito legal etc … porém, acho perda de tempo e dinheiro, criar algo ja criado, ainda mais se foi feito por algum órgão publico, que no caso usa meu dinheiro tbm kkkkkkk … mais vlw … abraço … parabéns
Gosto muito de ver esse movimento da galera criando novos frameworks etc, etc, etc … isso estimula, no caso, quem esta desenvolvendo a pensar de forma orientada e quem esta começando pode ter tbm um idéia de como fazer algo mais profissional … sei la … mais me lembro tbm que a tempos atras, tínhamos o framework ATENA, que tbm foi desenvolvido por algum órgão publico … que nao tinha nenhum IoC container próprio … maassss, foi criado para mesmo propósito, acredito …
E eu estava aqui pensando … ja que o Antena estava la … pq não melhorar o que ja existe … sei lá … mais fica a pergunta … não seria desperdício de tempo reinventar algo que ja existe ? temos tbm frameworks como o Click, NeoFramework … todos … acredito que criados para minimizar o tempo de desenvolvimento … acredito.
Portanto, como disse anteriormente, acho muito legal etc … porém, acho perda de tempo e dinheiro, criar algo ja criado, ainda mais se foi feito por algum órgão publico, que no caso usa meu dinheiro tbm kkkkkkk … mais vlw … abraço … parabéns[/quote]
Bom, como você bem falou o Demoiselle não foi o primeiro. E pode apostar que não será o último também.
Pois é pessoal,
já li de tudo sobre o demoiselle aqui no fórum…
Ainda bem que existem convergências e divergências, pois se fossemos todos iguais bastaria uma gripe para exterminar com a humanidade.
Agora, é interessante saber: tecnologia é uma ciência que avança em passos geométricos e para aqueles que acham que tudo vai terminar com o Demosielle podem ficar tranquilos pois não é o fim, o governo sabe disse, se preocupa com isso, e na EAP do projeto existem atividades para isso.
Para aqueles que se perguntam, puxa quanto o governo está gastando com isso? Podem ficar tranquilos que o governo está pagando o salário dos funcionários, e olha, são funcionários do executivo, então, pode deitar a sua cabecinha no travesseiro.
Para aqueles que querem saber sobre benefícios: Se você adotar um padrão, seja ele qual for, você ganha em produtividade, transparência, disponibilidade, segurança, etc, etc e o seu dinheirinho vai com certeza ser melhor aplicado. Mantenha o foco ou você vai se perder em uma simples pesquisa na internet.
Finalizando, a única coisa que realmente não tem jeito além da morte é agradar gregos e troianos, se fosse possível, cairíamos no que eu já escrevi acima, “uma gripe mataria a humanidade”. e as idéias, hummmm, que idéias?
A crítica, seja ela o gênero que for é bem-vinda, pois ela faz com que ajustemos o que precisa ajustar, mas infelizmente não vivemos só de crítica, sendo assim, tire a bunda da cadeira e faça a sua parte para a comunidade, seja ela livre ou proprietária.
Bem, o que foi disponibilizado até o momento foi apenas a documentação. Os fontes, JARs, etc, ainda não estão disponíveis ao público. Segundo o site está em trâmite jurídico para que os fontes possam ser liberados oficialmente.
O mais provável é que esse framework simplesmente morra de inanição, assim como todos os outros frameworks “ô mãe, olha pra mim eu sei fazer tudo!”.
Mas é aquela coisa, pelos documentos de arquitetura, tudo indica que é mais uma criação dos astronautas de software, que leram em fóruns e blogs que um VO é aquele objeto que guarda os dados que estão lá na tabela do banco de dados e nunca acharam estranho ver as operações separadas dos dados em uma linguagem orientada a objetos.
O mundo seria um lugar melhor se todos fossem obrigados a ler ao menos uma vez o “PoEAA” ou o “DDD”.
A grande maioria dos frameworks fazem a mesma coisa que um outro já faz… pra mim isto é lamentável… Ao invés de melhorar um que já existe, é construído outro que terá os seu problemas e desta forma será construído um outro e bla, bla, bla, bla…
