Frederico,

Em todas as IDEs Enterprise, isso vem embutido e concordo que eh bastante
util; mas daih a dizer que isso reduz a maior parte do seu tempo de
desenvolvimento, bem, eh algo que discordo.

Mesmo a escrita das instrucoes EJB-QL e a customizacao de como elas serao
interpretadas no application server jah consomem gde parte do tempo do
projeto se feitas diretamente. Mas  a manipulacao simples feita por alguns
session beans que funcionam como facade nao deixa de ser repetitiva; a unica
coisa que muda sao regras de nulidade, validacao em geral e encadeamento de
acoes.

Contudo, a maioria dos geradores de codigo nao estao preparados para, por
exemplo, inserir passos adicionais no seu workflow. Imagine que eu tenha um
gerador que use Struts pra chamar EJBs. Se ele nao tiver business delegates
e eu quiser que o sistema funcione com eles, qual minha dificuldade em fazer
isso? Por estas razoes um engine de regras de negocio definido na propria
plataforma J2EE faz falta.

Gostaria de saber se outros pensam da mesma forma.

Michael Nascimento Santos
Sun Certified Programmer for the Java 2 Platform
Sun Certified Programmer for the Java 2 Platform 1.4
Sun Certified Web Component Developer for J2EE
Moderador SouJava - www.soujava.org.br

----- Original Message -----
From: "Frederico Andrade Ramos" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Tuesday, March 25, 2003 8:58 AM
Subject: RES: [enterprise-list] Geradores de codigo




Michel,

eu acho que customiza��es s�o mais que normais qdo se usa
geradores de c�digo, crescendo junto com a complexidade das l�gicas
empregadas no sistema a ser desenvolvido. No
entanto, eu n�o vejo muita liga��o entre os geradores de c�digo e a
implementa��o da l�gica
de neg�cios.

Pelo menos no modelo que adotamos por aqui, onde usamos o
xdoclet e alguma coisa das ferramentas IDE, esses s�o 2 pontos bastante
distintos no processo de desenvolvimento. Pessoalmente eu n�o gosto de
geradores, mas acho o xdoclet (pra citar um exemplo) uma �tima forma de
aproveitar o tempo de um desenvolvedor, cuidando de tarefas q exigem mais
for�a bruta que qualquer outra coisa (aquele papo de "quebrar pedra").

Pegando um projeto com EJBs, por exemplo, eu acho xdoclet
legal pra montar as interfaces, pra cuidar dos deployment descriptors e at�
montar as classes de PK e value-object. Agora na hora de montar a l�gica de
:
- chama esses 2 entity,
- altera os campos "a" e "b" do primeiro, e o "c" do segundo
- chama um session pra fazer isso ou aquilo, etc...

A� num vejo lugar pra um gerador de c�digo pra isso... pq nessa hora
vc tem q botar a intelig�ncia pra funcionar, e geradores de c�digo, por
defini��o, s�o s� facilitadores pra atividades repetitivas e que n�o
requerem pensar pra serem desenvolvidas.

Espero ter deixado claro a minha posi��o...

Frederico


______________________________________________
Frederico Andrade Ramos
IT Developer
Nextel Telecomunica��es
Office : 55 11 3748-1411
Mobile : 55 11 9958-7004





> -----Mensagem original-----
> De: Michael Nascimento Santos [mailto:[EMAIL PROTECTED]
> Enviada em: ter�a-feira, 25 de mar�o de 2003 8:55
> Para: [EMAIL PROTECTED]
> Assunto: [enterprise-list] Geradores de codigo
>
>
> Falae pessoal,
>
> Vou iniciar uma discussao meio filosifica: o quanto voces acham que
> geradores de codigo - xdoclet/middlegen, egen, as proprias
> IDEs - conseguem
> efetivamente contribuir para a construcao de projetos
> corporativos com um
> numero relativamente grande de regras de negocio - vejam,
> negocio mesmo, do
> tipo: para completar o cadastro A, eh necessario tambem fazer
> o B; contudo,
> se no B o campo X receber o valor Y, o cadastro A poderah ser salvo
> imediamente e o cadastro C precisarah ser preenchido antes de
> se salvar o B
> (bem confuso, mas real) - e de fluxos de excecao?
>
> Digo isto porque sou a favor dos geradores de codigo, quer
> prontos, quer
> desenvolvidos in-house, mas tenho tido que fazer diversas
> customizacoes no
> codigo destas ferramentas, chegando ateh a reimplementar
> algumas partes
> completamente, para atender esta demanda. Voces se encontram
> em situacao
> similar ou as ferramentas de geracao de codigo funcionam meio que
> out-of-the-box pra voces? Serah que estas ferramentas nao precisam de
> abordagens diferentes no codigo-fonte delas, na arquitetura
> das classes,
> para que as personalizacoes de codigo nao exijam tantas
> alteracoes? Qual a
> opiniao de voces?
>
> []s
> Michael Nascimento Santos
> Sun Certified Programmer for the Java 2 Platform
> Sun Certified Programmer for the Java 2 Platform 1.4
> Sun Certified Web Component Developer for J2EE
> Moderador SouJava - www.soujava.org.br
>
> ---------------------------------------------------------------------
> Para cancelar a subscri��o, envie mensagem para:
> [EMAIL PROTECTED]
> Para comandos adicionais, envie mensagem para:
> [EMAIL PROTECTED]
>

---------------------------------------------------------------------
Para cancelar a subscri��o, envie mensagem para:
[EMAIL PROTECTED]
Para comandos adicionais, envie mensagem para:
[EMAIL PROTECTED]


---------------------------------------------------------------------
Para cancelar a subscri��o, envie mensagem para: [EMAIL PROTECTED]
Para comandos adicionais, envie mensagem para: [EMAIL PROTECTED]

Responder a