Opa Michael e demais, Gera��o de c�digo n�o necessariamente envolve apenas c�digo aixiliar, ou aquele c�digo burro e repetitivo. Existem algumas ferramentas que efetivamente geram c�digo chamado de neg�cio - aquele que realmente implementa as funcionalidades da aplica��o.
A problema que Michael levantou � v�lido porque quando h� gera��o de c�digo de neg�cio, existem quest�es como a arquitetura dos sistemas, padr�es de implementa��o, etc. A� entra a dificuldade em se customizar as ferramentas. Vejo isso na maioria dos clientes. Justamente por conta disso, a Qualiti (empresa em trabalho) desenvolveu o QualitiCoder, uma ferramenta de gera��o de c�digo (de neg�cio) cujo c�digo gerado pode ser facilmente customizado atrav�s de Wizards de configura��o. O processo de implanta��o sempre envolve customiza��o, mas sem aquele excesso de trabalho. Aqui vai o link: http://carlota.cesar.org.br/qualiti/newstorm.notitia.apresentacao.ServletDeS ecao?codigoDaSecao=183&dataDoJornal=atual Desculpem-me pela propaganda, mas � que a discuss�o bateu justamente com um dos motivos que levou � cria��o da ferramenta. Um abra�o, J�lio -----Mensagem original----- De: Michael Nascimento Santos [mailto:[EMAIL PROTECTED] Enviada em: ter�a-feira, 25 de mar�o de 2003 09:52 Para: [EMAIL PROTECTED] Assunto: Re: [enterprise-list] Geradores de codigo 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] --------------------------------------------------------------------- Para cancelar a subscri��o, envie mensagem para: [EMAIL PROTECTED] Para comandos adicionais, envie mensagem para: [EMAIL PROTECTED]
