http://www.guj.com.br/posts/list/12.java JForum - http://www.jforum.net Aqui no trampo vamos desenvolver um 'framework' pra servir de padrão no desenvolvimento de todos aplicativos(são todos pra uso próprio).
Pelo que andei conversando com o Philip, o cv, e lendo vários posts daqui e outras coisas mais, modelei mais ou menos como vai ser a arquitetura, gostaria de sugestões e/ou críticas vossas:

Vou ter um objeto que será a base para toda regra de negócio. Ele vai seguir uma sequência de inicialização, execução e finalização, que toda regra de negócio deverá implementar para seguir tal regra. EM outras palavras, vou ter uma interface com três métodos abstratos: init(), execute() e finalize(), e todo Business Object deverá implementar esta interface, e seus métodos.
Vou ter uma camada de DAO, utilizando um objeto padrão(DAOFactory) para as operações básicas de persistência, e esta camada DAO é quem fará a comunicação com a camada de persistência em si. Provavelmente Hibernate ou Entity Beans.

A interface ainda não está definida, mas provavelmente teremos um controle que comunicará a interface com a camada de negócios.

E então, o que eu poderia melhorar?Mudar?Acrescentar?Ou devo largar tudo e montar uma banca de jornal?

Obs:Sei que é meio vago definir uma arquitetura sem conhecer o negócio o qual ela servirá, mas é só pra fazer uma certa idéia do que seguir.
Grato]]> http://www.guj.com.br/posts/preList/21873/115803.java http://www.guj.com.br/posts/preList/21873/115803.java GMT
Está usando as patterns VO, DAO e Command. Que tal tirar o VO dali? ]]> http://www.guj.com.br/posts/preList/21873/115823.java http://www.guj.com.br/posts/preList/21873/115823.java GMT
O meu arrepio comecou aqui.

Desenvolver um framework ANTES de desenvolver uma aplicacao nao da certo: ou voce acaba com a aplicacao tendo que fazer gambiarras em cima do framework, ou a aplicacao nao sai ate mudarem o framework. Eh melhor fazer uma aplicacao primeiro, refatorar ela e tirar os pedacos genericos e transformar num framework do que tentar advinhar o que eh generico e o que nao eh. Alias, risque a palavra advinhar do dicionario.

[quote=Rafael Nunes]Pelo que andei conversando com o Philip, o cv, e lendo vários posts daqui e outras coisas mais, modelei mais ou menos como vai ser a arquitetura, gostaria de sugestões e/ou críticas vossas:

Vou ter um objeto que será a base para toda regra de negócio. Ele vai seguir uma sequência de inicialização, execução e finalização, que toda regra de negócio deverá implementar para seguir tal regra. EM outras palavras, vou ter uma interface com três métodos abstratos: init(), execute() e finalize(), e todo Business Object deverá implementar esta interface, e seus métodos.
Vou ter uma camada de DAO, utilizando um objeto padrão(DAOFactory) para as operações básicas de persistência, e esta camada DAO é quem fará a comunicação com a camada de persistência em si. Provavelmente Hibernate ou Entity Beans.[/quote]

Bom, algumas observacoes:

- O que acontece se o objeto nao puder seguir o padrao init/execute/finalize?

- Por que um objeto de negocios - que trata de uma regra de negocio especifica - vai ter que implementar uma interface alien dessa, que modela coisas que sao inicializaveis, executaveis e paraveis, sem necessariamente serem inicializaveis, executaveis ou paraveis?

- Por que ter uma "camada" de DAOs se voce nem sabe de que tipo de persistencia e nem de que tipo de queries voce precisa?

- finalize() eh um metodo que ja tem na java.lang.Object e serve pra outra coisa. Voce vai ter que arrumar outro nome

E, como uma imagem vale mil palavras, eis a minha descricao mais completa da sua arquitetura ate agora:

[img]http://photos6.flickr.com/7215636_40f771ef98_m_d.jpg[/img]]]> http://www.guj.com.br/posts/preList/21873/115832.java http://www.guj.com.br/posts/preList/21873/115832.java GMT
[quote=Rafael Nunes]
Vou ter um objeto que será a base para toda regra de negócio. Ele vai seguir uma sequência de inicialização, execução e finalização, que toda regra de negócio deverá implementar para seguir tal regra. EM outras palavras, vou ter uma interface com três métodos abstratos: init(), execute() e finalize(), e todo Business Object deverá implementar esta interface, e seus métodos.
[/quote]

Segundo isso, você deve ter objetos assim:

AdicionarUsuarioBO
RemoverUsuarioBO
editarUsuarioBO

Certo?

Se isso é verdade, me diz qual a diferença entre isso e um design procedural com funções com os mesmos nomes? (nota: esse excesso de Commands é sintoma de uso de Struts... acertei?)

Antes de pensar nas ações tomadas pelo sistema, pense nos objetos do sistema. Ops, problema aí: como pensar em objetos de sistemas futuros?

Fazer um framework tão genérico e manter boas práticas não é muito fácil... mais fácil você manter umf ramework vertical, sobre aquilo que sua emrpesa costuma ldiar (objetos relacionados ao negócio).

Se você trabalha com telecom, por exemplo, provavelmente vai conseguir ter uns objetos Assinante, BaseTerrestre, blablabla reutilizáveis, mas eles vêm com o tempo

Acho que você está se preocupando muito com o RAD da coisa ]]> http://www.guj.com.br/posts/preList/21873/115836.java http://www.guj.com.br/posts/preList/21873/115836.java GMT
E Rafael, apesar dos exelentes comentários de ambos, não se desespere, o jeito que você fez é melhor do que muita coisa por aí.

Sobre o comentário do cv sobre fazer a solução antes de surgir o problema, esclareço uma coisa a você: MVC não é um framework. Desenvolver uma maneira padrão para comunicação entre as camadas _poderia_ ser um framework.

Aliás, tem certeza que não há algo pronto no mercado para a necessidade de vocês? Se o objetivo é produção e não aprendizado, há o Genesis.]]> http://www.guj.com.br/posts/preList/21873/115838.java http://www.guj.com.br/posts/preList/21873/115838.java GMT
[quote=Rafael Nunes]
Aqui no trampo vamos desenvolver um 'framework' pra servir de padrão no desenvolvimento de todos aplicativos(são todos pra uso próprio).[/quote]

1. Suponho que além do obrigatório e basico Effective Java, você leu os 2 livros do Rod Johnson e percebeu claramente o trampo que virá pela frente.

2. É óbvio que você conhece muito bem os patterns Template Method, Strategy, Command, FrontController, ServiceToWorker e outros mais.

3. Tenho a certeza que você já estudou e usou muito os frameworks atuais como Struts, Webwork e Spring

4. Por fim você realmente precisa reinventar a roda.

Se respondeu sim a todas as 4 afirmações então siga em frente e boa sorte.

[]s
Luca ]]> http://www.guj.com.br/posts/preList/21873/115848.java http://www.guj.com.br/posts/preList/21873/115848.java GMT
Sim, o ponto eh que Command != Business Object... Command eh um metodo transformado em classe, pra poder ser tratado com uma granularidade um pouco diferente, ou quando voce tem parametros meio confusos e quer simplificar a coisa. Usar esse pattern pra "representar tudo" eh meio pisada de bola (de novo, olhem pra foto do cachorro) - e eh um dos defeitos do Prevayler, inclusive.

[quote=LIPE]E Rafael, apesar dos exelentes comentários de ambos, não se desespere, o jeito que você fez é melhor do que muita coisa por aí.[/quote]

Sem duvida. So de voce ter parado pra pensar e perguntar sobre isso ja torna o mundo um lugar melhor. ]]> http://www.guj.com.br/posts/preList/21873/115849.java http://www.guj.com.br/posts/preList/21873/115849.java GMT
O CV disse tudo:

[quote="CV"]
Desenvolver um framework ANTES de desenvolver uma aplicacao nao da certo: ou voce acaba com a aplicacao tendo que fazer gambiarras em cima do framework, ou a aplicacao nao sai ate mudarem o framework. Eh melhor fazer uma aplicacao primeiro, refatorar ela e tirar os pedacos genericos e transformar num framework do que tentar advinhar o que eh generico e o que nao eh. Alias, risque a palavra advinhar do dicionario.
[/quote]

Todo o framework tem um determinado nível de "genericidade", ou seja, ele é generico e configurável até certo ponto. Como o framework é para a sua empresa e nada mais, eu sugiro vc criar o framework fortemente acoplado as decisões da sua empresa.

Lembre-se que se acontecer alguma mudança nessas decisões, alguém da sua empresa pode alterar o framework em nível de código fonte. Vc não precisará criar inúmeros arquivos de configuração para utilizar o framework, e com isso, você ganha muito tempo de desenvolvimento.

Em outras palavras, fazer coisas genéricas nem sempre é a melhor saída, porque, além de esperar por uma mudança que talvez nunca aconteça, é possível que o código ainda esteja errado.

Como disse o CV, crie o seu framework ao longo do tempo em que desenvolve o sistema. Assim que detectar que algo pode ser "genérico" você o faz e separa dos fontes da aplicação.

Refactoring é a palavra mágica ]]> http://www.guj.com.br/posts/preList/21873/115853.java http://www.guj.com.br/posts/preList/21873/115853.java GMT Acho mais fácil situar-me primeiro. Onde trabalho é uma Universidade, logo, tudo que for desenvolvido é pra uso próprio. Já respondendo a última proposição do Lipe, usar algo terceiro está fora de cogitação, o que eles querem mesmo é desenvolver um framework, um padrão que deverá ser seguido por todas aplicações aqui desenvolvidas.

[quote=Lipe] Está usando as patterns VO, DAO e Command. Que tal tirar o VO dali?[/quote]
O VO que se refere é o Controller?
Bem o sistema aqui é distribuído, os .jsp ficam em máquina separada dos .class. Iremos usar um Session Bean para comunicação entre a View e o restante da aplicação, sendo que não conheço maneira mais simples de comunicação RMI. Aliás, eu consigo conversar com o Hibernate através de RMI?

[quote=Lipe]Desenvolver uma maneira padrão para comunicação entre as camadas _poderia_ ser um framework[/quote]
Bingow, é exatamente isso!!!O que estamos querendo é um padrão para comunicação E desenvolvimento.]]> http://www.guj.com.br/posts/preList/21873/115856.java http://www.guj.com.br/posts/preList/21873/115856.java GMT O VO que se refere é o Controller?
Bem o sistema aqui é distribuído, os .jsp ficam em máquina separada dos .class. Iremos usar um Session Bean para comunicação entre a View e o restante da aplicação, sendo que não conheço maneira mais simples de comunicação RMI. Aliás, eu consigo conversar com o Hibernate através de RMI?[/quote]

JSP longe dos .class?

Isso me diz que você está usando JSP como se fosse ASP, e isso por si só já é um problema

(aliás, conceitualmente isso não é possível, já que suas JSP viram .class )

Passando ao próximo passo, sua camada de View não deve contatar a camada onde o Hibernate está localizado, para isso coloque uma camada de modelo/negócios no meio.

Nessa camada ficam os objetos de domínio, para acessá-la você pode até utilizar um Stateless Session Bean se estiverem em computadores diferentes, ams não faça isso se não souber quando NÃO utilizar um EJB

Logo, não tem proque voc~e acessar o hibernate, DAOs e etc. pela View, se você precisar colocar sua camada de persistência numa máquina diferente, é outro papo, mas aidna assim a comunicação é entre a camada do meio e a de persistência

]]> http://www.guj.com.br/posts/preList/21873/115857.java http://www.guj.com.br/posts/preList/21873/115857.java GMT
É exatamente isso Carlos, queremos criar por exemplo um padrão para todas aplicações por exemplo conversarem com o banco. Estamos entre duas opções, Hibernate e Entity Beans. Ou seja, toda aplicação, ou todo processo que quiser conversar com o banco, deverá passar pelo DAO e este conversará com o Hibernate/Entity

[quote=cv]O que acontece se o objeto nao puder seguir o padrao init/execute/finalize[/quote]

Como assim?Isto não será por objeto, e sim por caso de uso, os métodos serão na verdade preCondicoes(), execute() e posCondicoes(). Onde serão responsáveis respectivamente por executar pré condições antes do caso de uso, executá-lo em si, e alguma tarefa que deva ser executada após a sua finalização.


[quote=cv] - Por que ter uma "camada" de DAOs se voce nem sabe de que tipo de persistencia e nem de que tipo de queries voce precisa?[/quote]
A persistência será Hibernate ou Entity Beans, o que não quero e creio que não seria recomendável, é dentro do meu objeto de negócio chamar diretamente os métodos do Hibernate/Entity

[quote=cv] - finalize() eh um metodo que ja tem na java.lang.Object e serve pra outra coisa. Voce vai ter que arrumar outro nome[/quote]
Na verdade o nome dele é posCOndicoes(). É que não quis estragar a surpresa... ;o)]]> http://www.guj.com.br/posts/preList/21873/115858.java http://www.guj.com.br/posts/preList/21873/115858.java GMT [/quote]
Acho que não é uma boa hora pra perguntar quem é Rod Johnson...

[quote] 2. É óbvio que você conhece muito bem os patterns Template Method, Strategy, Command, FrontController, ServiceToWorker e outros mais. [/quote]
Na verdade só o FrontController, que é o que usamos aqui hoje.

[quote] 3. Tenho a certeza que você já estudou e usou muito os frameworks atuais como Struts, Webwork e Spring [/quote]
Struts e Webwork sim, mas acho meio complicado implementar eles pras necessidades que temos aqui.

[quote] 4. Por fim você realmente precisa reinventar a roda. [/quote]
O que ando um pouco receoso é de usar uma porrada de frameworks e componentes terceiros e acabar tendo de ajustar minhas aplicações pras necessidades deles.]]> http://www.guj.com.br/posts/preList/21873/115862.java http://www.guj.com.br/posts/preList/21873/115862.java GMT Isso me diz que você está usando JSP como se fosse ASP, e isso por si só já é um problema
(aliás, conceitualmente isso não é possível, já que suas JSP viram .class ) [/quote]
Na verdade hoje a estrutura está assim, uma máquina com o tomcat rodando os JSP e uma outra rodando os .java

[quote] Passando ao próximo passo, sua camada de View não deve contatar a camada onde o Hibernate está localizado, para isso coloque uma camada de modelo/negócios no meio. [/quote]
É exatamente isso que eu tentei fazer com meus Business Objects e DAO´s.

[quote] Nessa camada ficam os objetos de domínio, para acessá-la você pode até utilizar um Stateless Session Bean se estiverem em computadores diferentes, ams não faça isso se não souber quando NÃO utilizar um EJB[/quote]
Hoje já utilizamos o Session Bean pra isso, e provavelmente é o que continuaremos a utilizar, pois não encontrei maneira mais fácil.

[quote] Logo, não tem proque voc~e acessar o hibernate, DAOs e etc. pela View, se você precisar colocar sua camada de persistência numa máquina diferente, é outro papo, mas aidna assim a comunicação é entre a camada do meio e a de persistência[/quote]

Acho que não me expliquei direito. É exatamente isso que não quero fazer, convesar diretamente minha View com minha camada de persistência. Por isso que coloquei os BO e DAO´s. E provavelmente teremos a camada de persistência em uma outra máquina e pra isso acho que será mais Session Beans pra conversar DAO com Persistência]]> http://www.guj.com.br/posts/preList/21873/115866.java http://www.guj.com.br/posts/preList/21873/115866.java GMT
http://www.martinfowler.com/eaaCatalog/domainModel.html

E um dos problemas que causam Domain Models ruins:

http://www.martinfowler.com/bliki/AnemicDomainModel.html

(quantas vezes esse link já foi dado no GUJ?)
]]> http://www.guj.com.br/posts/preList/21873/115870.java http://www.guj.com.br/posts/preList/21873/115870.java GMT
Só para mim, acho que você já recomendou umas 10 vezes esse link...


Edit:
A impresão que tenho olhando essa pseudo-arquitetura que fiz, é que posso gerar um enorme trabalho desnecessário, ou engessar demais o desenvolvimento das aplicações, como o cachorro do cv. Mas é só uma impressão, tipo que eu to sempre esquecendo algo quando saio pra viajar. Talvez sim, talvez não.]]> http://www.guj.com.br/posts/preList/21873/115874.java http://www.guj.com.br/posts/preList/21873/115874.java GMT http://www.guj.com.br/posts/preList/21873/115877.java http://www.guj.com.br/posts/preList/21873/115877.java GMT ]]> http://www.guj.com.br/posts/preList/21873/115886.java http://www.guj.com.br/posts/preList/21873/115886.java GMT
Alguém já ouviu falar ?
]]> http://www.guj.com.br/posts/preList/21873/115887.java http://www.guj.com.br/posts/preList/21873/115887.java GMT
É que neste caso, ao menos na estrutura da aplicação que ja tem rodando aqui, os servlets estão na mesma máquina do JSP, o que está em máquina diferente são os EJB´s e Business Objects.]]> http://www.guj.com.br/posts/preList/21873/115888.java http://www.guj.com.br/posts/preList/21873/115888.java GMT
Esse negóciod e tabelas é engraçado... vamos colcoar tudo em tabelas e as manipular! Claro, mas... não é isso que programas estruturados fazem com registros, struts, resultsets, datasets...?]]> http://www.guj.com.br/posts/preList/21873/115889.java http://www.guj.com.br/posts/preList/21873/115889.java GMT

Rafael, então realmente precisa de uma estrutura de comunicação. EJBs fazem o serviço para você, mas se quiser, pode dar uma olhada no [url=http://www.retrogui.com/cgi-bin/wiki_dualrpcserver.pl/DualRpcServer]DualRpc[/url].
Pode resolver o seu problema com muito mais facilidade.]]> http://www.guj.com.br/posts/preList/21873/115893.java http://www.guj.com.br/posts/preList/21873/115893.java GMT
Pra que DualRpc?]]> http://www.guj.com.br/posts/preList/21873/115898.java http://www.guj.com.br/posts/preList/21873/115898.java GMT Talvez tenham uma pra jogar paciência nos horários de folga... ;o)]]> http://www.guj.com.br/posts/preList/21873/115900.java http://www.guj.com.br/posts/preList/21873/115900.java GMT Ao invés de EJBs.]]> http://www.guj.com.br/posts/preList/21873/115907.java http://www.guj.com.br/posts/preList/21873/115907.java GMT Ao invés de EJBs.[/quote]

Invés de RMI, tu diz, né?]]> http://www.guj.com.br/posts/preList/21873/115908.java http://www.guj.com.br/posts/preList/21873/115908.java GMT
Lipe, que está sempre certo.

]]> http://www.guj.com.br/posts/preList/21873/115912.java http://www.guj.com.br/posts/preList/21873/115912.java GMT
Estou considerando seriamente a possibilidade de ir pro interior vender patos e javali. Aliás, carne de javali é bem saborosa, interessa?]]> http://www.guj.com.br/posts/preList/21873/115917.java http://www.guj.com.br/posts/preList/21873/115917.java GMT
Por isso, sendo contrário ao que falaram, atenha-se ao seu plano básico. Mas saiba que, sem a experiência necessária, é _bastante_ improvável que saia um framework do seu trabalho todo; é mais provável surgir uma solução completamente engessada e fedida (como aconteceu comigo). E tudo bem! Já que é para aprendizado, se esbalde com seus erros ]]> http://www.guj.com.br/posts/preList/21873/115926.java http://www.guj.com.br/posts/preList/21873/115926.java GMT
E em todo caso, sempre haverão patos e javalis.... ;o)]]> http://www.guj.com.br/posts/preList/21873/115931.java http://www.guj.com.br/posts/preList/21873/115931.java GMT e, lógico que isso não faz o menor sentido. Assim como escrever um framework do zero por escrever...]]> http://www.guj.com.br/posts/preList/21873/115932.java http://www.guj.com.br/posts/preList/21873/115932.java GMT
Mas aí o aprendizado seria bem menor. Pense nos pobres patinhos ]]> http://www.guj.com.br/posts/preList/21873/115943.java http://www.guj.com.br/posts/preList/21873/115943.java GMT
Nunca disse que não Ele é que mencionou antes nessa thread que não podia usar frameworks de terceiros. Isso que quis enfatizar: não faz sentido não usar! Inclusive, a melhor solução a longo prazo sempre acaba sendo construir um framework em cima de outros frameworks que você usa nos seus projetos. Mas isso só pode ser feito após alguns projetos

[quote]o Rafael poderia muito bem usar Webwork de um lado, a parte de comunicação do Genesis no meio e Hibernate no fim.

Mas aí o aprendizado seria bem menor[/quote]

Não. Depende do que você quer aprender. Se você faz tudo no braço (inclusive a persistência), você aprende as coisas no nível mais baixo, mas a tendência é que sua "overall architecture" seja uma porcaria. E, no dia a dia, é (geralmente) muito mais importante que você saiba escrever uma solução clara e fácil de manter, não a que é mais eficiente que o Hibernate, por exemplo.]]> http://www.guj.com.br/posts/preList/21873/115949.java http://www.guj.com.br/posts/preList/21873/115949.java GMT O que ele faria é simplesmente direcionar as chamadas da View pra camada dos Business Object. Aí lá vinha mais bibliotecas, mais xml, mais configuração, e isso eu poderia resolver com um simples servlet, estou errado?]]> http://www.guj.com.br/posts/preList/21873/115965.java http://www.guj.com.br/posts/preList/21873/115965.java GMT
Eu conheço um certo sistema produzido com algo muito próximo dessa estrutura que você sugeriu, só que ele usa Session Beans como os "business objects" do framework que vc fez.

Resultado? Hoje existem quase 400 Session Beans, cada um faz uma coisa apenas (adiciona usuário, remove usuário), o deployment descriptor é ilegível (ok, nenhum descriptor é lá muito legível...) e simplesmente [b]não[/b] escala.]]> http://www.guj.com.br/posts/preList/21873/115969.java http://www.guj.com.br/posts/preList/21873/115969.java GMT E temos um Session Bean por módulo, por exemplo, um Session Bean pra módulo financeiro, um Session Bean pra módulo acadêmico, outro pra relatório.
Ao invés de termos um Session Bean pra cada caso de uso, temos um Session Bean com milhares de métodos, e esses chamam os objetos de negócio.


Ps:Tá muito 'procedural' esta arquitetura?]]> http://www.guj.com.br/posts/preList/21873/115971.java http://www.guj.com.br/posts/preList/21873/115971.java GMT Ao invés de EJBs.[/quote]

Você ainda pode usar JNDI com classes simples no Container. Não Pode?]]> http://www.guj.com.br/posts/preList/21873/116012.java http://www.guj.com.br/posts/preList/21873/116012.java GMT
[quote=Rafael Nunes]
Acho que não é uma boa hora pra perguntar quem é Rod Johnson...
[/quote]

Rod Johnson, autor de J2EE Design and Development, um dos melhores livros de arquitetura J2EE que conheço e cujo capítulo 4 é de leitura [b]obrigatória[/b] para todo cara que pretende escrever código Java além do Hello World. Ele escreveu também J2EE Development without EJB e é o criador do Spring.

[quote=Rod Johnson, J2EE Design and Development, pág 166]
Why (and How) Not to reinvent the Wheel[/quote]

São cerca de cinco páginas dizendo o que o CV já disse, que eu repeti e o Michael corroborou.

Eu sou tão fã do Rod Johnson que vou afirmar o seguinte: assim como alguns dizem que programador Java que nunca leu Effective Java tem grande chance de escrever código merda e ilegível, arquiteto de sistemas que nunca leu Rod Johnson tem grande chance de criar sistemas dificeis de manter e extender (como casas que não servem para morar).

E finalmente os patterns que citei são os mínimos necessários para escrever um framework meia boca. Se você não conhece Template Method e Strategy tem grande chance de também nunca ter ouvido falar em inversão de controle. O Service To Worker é como o Command é usado pelos frameworks para preparar a resposta dinâmica para a camada de apresentação. A importância de conhece-lo bem é para não usar Dispatcher View que viola o MVC.

[]s
Luca]]> http://www.guj.com.br/posts/preList/21873/116040.java http://www.guj.com.br/posts/preList/21873/116040.java GMT
Eu acho que acabei usando o termo errado, creio eu que o que estou fazendo não é bem um framework, é tipo criar um padrão, um contrato para o desenvolvimento das aplicações internas.
Andei reavaliando o esquema todo, e me incomodou um pouco esta estrutura de Command, de toda regra que negócios ter de seguir um fluxo herdado da interface. Mas me incomoda mais ainda deixar o desenvolvimento dos objetos de negócio a esmo, não criar um contrato para isso. Principalmente porque a maioria dos programadores são ou vieram do mundo procedural, o que eu queria era tipo obrigá-los a programar OO(sim, eu sei que é bem difícil eu conseguir isso se não houver um comprometimento deles, e não, ameaças de morte/demissão/desconto de salário não são viáveis neste caso).

Alguma sugestão?]]> http://www.guj.com.br/posts/preList/21873/116127.java http://www.guj.com.br/posts/preList/21873/116127.java GMT
Eu acho que acabei usando o termo errado, creio eu que o que estou fazendo não é bem um framework, é tipo criar um padrão, um contrato para o desenvolvimento das aplicações internas.
Andei reavaliando o esquema todo, e me incomodou um pouco esta estrutura de Command, de toda regra que negócios ter de seguir um fluxo herdado da interface. Mas me incomoda mais ainda deixar o desenvolvimento dos objetos de negócio a esmo, não criar um contrato para isso. Principalmente porque a maioria dos programadores são ou vieram do mundo procedural, o que eu queria era tipo obrigá-los a programar OO(sim, eu sei que é bem difícil eu conseguir isso se não houver um comprometimento deles, e não, ameaças de morte/demissão/desconto de salário não são viáveis neste caso).

Alguma sugestão?[/quote]

Matá-los''

talvez fosse interesante mostrar porque eles deveriam aprender OO?
em que esta padronização sua melhoraria todo o processo?
E a você se realmente é necessária uma mudança nesse sentido?

Caso consiga algum volutário depois disso
pode iniciar com eles, com o tempo os demais vão se juntando ao grupo.]]> http://www.guj.com.br/posts/preList/21873/116130.java http://www.guj.com.br/posts/preList/21873/116130.java GMT A gente trabalha com uma plataforma OO, não faria sentido programar proceduralmente com ela.


[quote] em que esta padronização sua melhoraria todo o processo? [/quote]
Hoje temos uma equipe de 9 programadores, todos vieram e ainda programam em tecnologias procedurais. O problema é que hoje na hora do desenvolvimento, cada um cria as classes, os objetos a esmo. Acha o jeito mais fácil ou mais cômodo de fazer e sair criando classes e métodos. Pode imaginar como está a arquitetura e manutenção desta aplicação?

[quote] E a você se realmente é necessária uma mudança nesse sentido?[/quote]
Sim, pelos motivos acima.]]> http://www.guj.com.br/posts/preList/21873/116150.java http://www.guj.com.br/posts/preList/21873/116150.java GMT
Só cuidado com picaretas, e essa é a parte difícil em contratar um consultor. Desconfie de muitas siglas de empresas e certificações pop.

]]> http://www.guj.com.br/posts/preList/21873/116153.java http://www.guj.com.br/posts/preList/21873/116153.java GMT
A sugestao do Kiviano eh otima, mas esconder os corpos eh [b]sempre[/b] uma tarefa ingrata. O que voce pode fazer eh uma workshopzinha rapida de Test-Driven Development, e rejeitar qualquer codigo no CVS que nao tenha um teste unitario provando que ele deve existir, e que ele funciona. Enfase no "provando que ele deve existir", por favor.

Demora uma ou duas semanas pra montar um sistema de build automatizado que toma conta disso pra voce, caso voce nao tenha nenhuma experiencia com a coisa (de uma olhada no DamageControl, CruiseControl e CruiseControl.NET).

Isso, por si so, ja aumenta a qualidade do codigo - mesmo que seja uma porcaria nao-OO, pelo menos voce sabe se funciona ou nao inspecionando os testes unitarios, e como tem sempre uma base de testes por perto, fica facil refatorar e fazer a coisa mais OO.

Outro esquema que pode ajudar bastante eh se livrar de metade das maquinas da sala, e botar todo mundo pra fazer pair programming. Assim, a comunicacao na equipe aumenta, e a troca de conhecimentos e aprendizados se agiliza. Dai, ja que voce ta fazendo integracao continua e pair programming, mesmo, aproveite pra dar uma lida sobre XP, e adapte as ideias que mais convierem (ou force aqueles que decidem esse tipo de coisa a adota-las. Armas apontadas pra cabeca do individuo e/ou familiares dele geralmente resolvem essas decisoes com uma eficacia incrivel) ]]> http://www.guj.com.br/posts/preList/21873/116156.java http://www.guj.com.br/posts/preList/21873/116156.java GMT
Samuel esnobe diz que nao demora nao

Montei o ambiente em 4 dias com DamageControl, Maven, CVS e Eclipse. Ficou bem legal (servidor HPUX rodando DC e Maven, repositorio central do Maven para desenvolvedores e servidor, CVS em outro servidor e Eclipse para desenvolvimento) ... recomendo, o trabalho de manutencao é incrivelmente baixo (quase nulo) depois que estiver tudo redondo.]]> http://www.guj.com.br/posts/preList/21873/116165.java http://www.guj.com.br/posts/preList/21873/116165.java GMT http://www.guj.com.br/posts/preList/21873/116167.java http://www.guj.com.br/posts/preList/21873/116167.java GMT Sim, pelos motivos acima.[/quote]


Fiz as indagações porque hoje há um grande BOOM entorno de OO,
Padrões, e bla bla, e ta cheio de especialistas nisso

Aqui mesmo quando aparece um cara querendo saber fazer uma
jsp + servlet, ja aparecem vários experts mandando o cara estudar padrões,
que isso ta erado, que aquilo ta á errado.

PS: foi ironia mesmo...

Enfim, você nunca vai chegar a usar padrões se não sabe OO,
e isso vale para seus desenvolvedores.
A curva de aprendizado é muito ingrime, e quando você chegar ao topo dela,
vai olhar pra baixo e dizer "putz, subi um degrau",
ai quando tiver chegando no segundo vai olhar pra traz e dizer "putz, meu primeiro degrau não suporta o segundo"
vamos reestudar, refatorar, reeaprender, e assim o ciclo segue.

Só queria atentar ao fato de que não use OO, não use, Padrões,
não use qualquer coisa se não tiver certeza de que no futuro vai agregar algum valor,
e se não souber o que está fazendo.

Do contrário continuará programando estruturalmetne o resto da vida mesmo usando Java.
Ou acham que quem usa Java obrigatoriamente programa OO?

é preciso tomar cuidado quando se diz vamos programar OO,
maravilha, somos fodas, ai agente põe uns padrõezinhos aqui e
ali e fica show. Que show : ))

no mais estude OO(sempre), padrões(sempre), e atentando ao fato de que sempre mudam, e que NÃO deve adotar a idéia de alguém completamente, mesmo este sendo O CARA, formule as suas idéias, e proponha novas idéias.


PS2: saiu uma redação
PS3: foi um desabafo sim ]]> http://www.guj.com.br/posts/preList/21873/116170.java http://www.guj.com.br/posts/preList/21873/116170.java GMT
Diga que existe uma limite X para LOC/método, metodos/classe, atributos/classe, complexidade ciclomática e violações da lei de Demeter.

O código inicial vai ser caótico, mas em pouco tempo ou cai a ficha que sem OO não vai para frente ou explode.]]> http://www.guj.com.br/posts/preList/21873/116184.java http://www.guj.com.br/posts/preList/21873/116184.java GMT
Diga que existe uma limite X para LOC/método, metodos/classe, atributos/classe, complexidade ciclomática e violações da lei de Demeter.

O código inicial vai ser caótico, mas em pouco tempo ou cai a ficha que sem OO não vai para frente ou explode.[/quote]

isso não cairia numa prática de métodologia agil chamada refactoring? ]]> http://www.guj.com.br/posts/preList/21873/116187.java http://www.guj.com.br/posts/preList/21873/116187.java GMT
Em um outro projeto a gente colocou isso no CVS... um commit demorava alguns minutinhos, pq ele tinha que analisar o codigo antes de aceitar o commit, mas valia a pena. O codigo so entrava no CVS se, e somente se, ele nao tivesse nenhum problema com sintaxe, imports inuteis, nenhum warning nem utilizacao de metodo ou API deprecada. Depois, a gente foi deixando a coisa mais divertida: nenhum commit passava se o codigo tivesse alguma dependencia circular, ou se o cliente usasse classes do servidor (ele tinha que falar com o servidor atraves do pacote de classes comuns), e todos os arquivos .java tinham que ter o copyright e a licenca no topo.

Quando alguem pegava uma classe pra editar que violasse algum desses requisitos, tinha que arrumar ou nao fazia commit. Em 6 semanas o codigo tava lindinho de novo ]]> http://www.guj.com.br/posts/preList/21873/116206.java http://www.guj.com.br/posts/preList/21873/116206.java GMT
Quanto a dica do Phillip de contratatr um consultor eu cheguei a cogitar, porém foi refutada no primeiro comentário que fiz. Por um lado é ruim pois sei que vou quebrar muito a cabeça pra resolver coisas simples que poderiam ser resolvidas sem tanta burocracia, por outro creio que vai ser bom porque ou eu aprendo alguns padrões, ou aprendo como não utilizar certos padrões, de qualquer forma, aprendo.

Quanto ao build no CVS que o cv dugeriu, nós usamos o Source Safe , vou tentar adaptar alguma dessas ou outra ferramenta nele, foi bem legal a idéia.]]> http://www.guj.com.br/posts/preList/21873/116244.java http://www.guj.com.br/posts/preList/21873/116244.java GMT Quanto ao build no CVS que o cv dugeriu, nós usamos o Source Safe , vou tentar adaptar alguma dessas ou outra ferramenta nele, foi bem legal a idéia.[/quote]

Concordo, mas cuidado para não criar um clima ruim, deixe claro os propósitos da ferramenta, antes que alguém coloque um desenho seu como alvo de tachinhas no banheiro

Aproveita, entra numa clínica dessas por aí, isntala o Subversion e larga as drogas Esse Microsoft SourceSafado ninguém merece!]]> http://www.guj.com.br/posts/preList/21873/116248.java http://www.guj.com.br/posts/preList/21873/116248.java GMT
[img]http://zuckuss87.tripod.com/cats_vs_dogs/images/hurt_dog.jpg[/img]]]> http://www.guj.com.br/posts/preList/21873/116271.java http://www.guj.com.br/posts/preList/21873/116271.java GMT
Mas como vocês estão fazendo essa análise do código antes do commit no cvs? Através de um build file do ant?

Desculpe minha ignorância do assunto... ]]> http://www.guj.com.br/posts/preList/21873/123644.java http://www.guj.com.br/posts/preList/21873/123644.java GMT
O importante eh nao tornar as sessoes de commit infernais, tambem... pq antes codigo ruim gerenciado pelo CVS do que codigo ruim esquecido na maquina de alguem...]]> http://www.guj.com.br/posts/preList/21873/123692.java http://www.guj.com.br/posts/preList/21873/123692.java GMT
Eu achava que essa validação era feita no cliente, mas aí ficava meio sem sentido a coisa...

Valeu pela resposta!
]]> http://www.guj.com.br/posts/preList/21873/123769.java http://www.guj.com.br/posts/preList/21873/123769.java GMT
Share! ]]> http://www.guj.com.br/posts/preList/21873/125679.java http://www.guj.com.br/posts/preList/21873/125679.java GMT