Case pra discussão: lista de preços

Programação Arquitetura
#1

A um ano e meio atrás desenvolvi uma aplicação web com ejb em um projeto que estava orçado para 6 meses. Até aí tudo bem, fizemos o levantamento de requisitos, casos de uso, prototipagem, web design, modelagem e etc. Tudo muito informal e a princípio sem maiores problemas.

Por questões internas (simplesmente pra não dizer que era um projeto novo e, com isso, irritar alguém lá do alto escalão que iria se tocar que a verba para “manutenção” que ele havia liberado na verdade estaria sendo usada para algo que ele achava que já estava feito) essa aplicação iria entrar “embaixo” de uma outra aplicação web com ejb sendo que ambas tratavam de assuntos diferentes.

Logo nos primeiro meses lá, enquanto ainda estava levantando meu sistema, tive a infeliz oportunidade de “ver” essa outra aplicação ao dar uma força pro analista que estava segurando o pepino (hoje um grande amigo meu, figuraça) e olha só o quê eu vi:

  • documentação 0;
  • usava um “framework” proprietário que um departamento deles lá para pesquisa e desenvolvimento havia escrito e que se tornara obrigatório em todas aplicações na intranet (queria ser um struts mas não ajudava em nada, cheio de gambiarras e erros de conceito que tentava fazer de tudo um pouco nos lugares errados e sempre que alguém precisava alterar não podia pq estava em uma versão mais recente mas ninguém tinha coragem de atualizar);
  • curiosamente era o 2o projeto ejb na fábrica (o primeiro havia sido escrito como prova de conceito pro “framework” acima);
  • entitys 1.0 de tabelas DB2 gigantes (mais de 50 mil linhas por tabela - uma delas com mais de um milhão de linhas) que haviam sido desenvolvidos a lá receita de bolo pq a equipe não teve tempo de receber treinamento em ejb;
  • uma penca de session stateless, entupido de regra de negócio, que nunca ninguém dava remove;
  • DAO no meio da história (muito mal escrito, controlando transação que nem o nariz e vira e mexe ferrando com os entitys);
  • Toda a equipe de desenvolvimento original debandandara pra outros projetos em clientes externos ou pra outras empresas;

Não precisa dizer que ninguém havia rolado tunning nos servers (só pra inicilizar demorava mais de 4 horas)

Certo, ele estava sozinho e logo de cara vi que o sistema que eu estava desenvolvendo, depois de entregue, ia ser empilhado nas mãos dele. Depois de uma longa sabatina (e acertar o server pra ele que não estava inicializando pq tava estourando os 4gb de memória) voltei pra minha báia.

Em uma das reuniões de requisitos nosso gerente solta um pára-quedas daqueles bem fedorentos: Vamos precisar auditar as tabelas da aplicação nova - aproveita e faz isso na velha tb pois eu sei que ainda não está fazendo (e deveria, já havia sido pago).

Na época eu não sabia (muito menos ele) que os entitys 1.0 disparam atualizações no banco por cada coluna alterada (50 colunas significam 50 comandos update no banco), coisa que vimos da pior forma: depois de passar 4 dias escrevendo triggers para aquela auditoria que deveria ter sido feita (e que, no final das contas, como não dava para “desligar” mais de 30 entitys sem parar a aplicação, ficou por auditar apenas as tabelas manipuladas pelo DAO).

Um mês e meio depois, com tudo que eu precisava em mãos começamos a fase de projeto, eu e 2 desenvolvedores.

Até então sabia que:

  1. Base de usuários: Américas, todas filias, mais ou menos 200 usuários;
  2. Disponibilidade: alta, 24x7;
  3. Volume de dados: médio com crescimento constante, toda semana uma nova planilha de preços com mais ou menos 2000 linhas, mantendo histórico;
    04] A periodicidade semanal das planilhas poderia a qq momento se tornar diária em função da variação do dólar;
  4. Haveria necessidade de transação distribuída;
  5. Ia precisar de uma rotina de backup e expurgo - senão haja banco;
  6. Não ia querer misturar minha base com o legado. Queria um schema separado pra facilitar e isolar o item 6;
    08] 4 servers: 1 web (tomcat com conector), 2 app (WAS 5 alguma coisa) e um db2 7 rodando num Z-Series;
  7. Sem ambiente de homologação;
  8. Ia ter de usar aquele “framework” maldito;
  9. Ia ter ejb mesmo (por causa dos itens 2 e 5);
  10. Não ia poder usar entitys (e nem estava afins - entity 1.0 ? quem ia querer ?) pois a minha aplicação teria de ser auditada e tb porque eu não estava afins de jogar fora meus 4 dias de trigger;
  11. Pela natureza da aplicação e questões de segurança teria de disponibilizá-la também como serviço;
  12. Ia ter muita tela de consulta (identificamos mais de 50 no levantamento inicial);
  13. Só restava um mês e meio para o término da primeira iteração;
  14. Tinha de ser simples, simples e simples pois não ia ter córum pra dar manuteção sem ficar me pentelhando o juízo de madrugada antes do término do meu contrato.

Apesar da empresa ser a empresa que era não havia ninguém conntrolando riscos e por conseguinte ficou tudo por minha conta mesmo.

O quê eu decidi:

  1. Ia ter ejb mesmo;
  2. Ia usar POI pra carregar as planilhas com as listas de preços;
  3. Ia usar session façades, business interface, pojo e dao;
  4. CachedRowSet nas 50 consultas pra reduzir o número de value objects e facilitar mundanças nas mesmas;

O quê eu enguli:

  1. O “Framework”;
  2. WAS 4;
  3. Muita pizza, café e cigarro pra fazer o CachedRowSet funcionar no WAS 4 com j9 1.3;

O quê eu “acho” que aprendi:

  1. Que eu preciso discutir com alguém qdo usar o CachedRowSet;
  2. Que eu preciso me assegurar que o ambiente de produção vai ter realmente as versões (ipse litrem) dos produtos que me foram indicados;
  3. que entity 1.0 é pior do que eu imaginava;

Discussão:

  1. O quê vc faria além? Pq?
  2. O quê vc faria diferente? Pq?
  3. O quê vc não faria? Pq?

Conforme o assunto esquentar (se esquentar) vou agregar mais info aqui.

#2

Utilizaria Hibernate e Spring.

Hibernate vai te eliminar tantos destes problemas com JDBC que você nem imagina, além de remover qualquer resquício de Transfer Object (Value Objects são outra coisa) e o Spring te oferece serviços que você tem com EJBs para POJOs, o que permitiria uma fina camada de EJBs apenas, e se necessário.

#3

[quote=pcalcado]Utilizaria Hibernate e Spring.
[/quote]

mesmo não tendo uma equipe treinada pra isso? Ambos tem uma boa curva de aprendizado (por menor que seja) e isso sempre agrega risco, IMO.

Isso foi a um ano e meio atrás, spring tava muito cru e era hibernate 2.

#4

Adotei o Hibernate 3.1 em dois projetos novos da empresa com sucesso. Eu estudei por conta e decidi adotar. A equipe não era treinada. Um novo membro treinado e experiênte nisso acabou entrando na equipe, o que ajudou. Mas acho que vale a pena.

#5

Há um ano e meioa trás eu fiz a m3rd@ de usar JDBC puro numa aplicação com milhares de registros por tabela e com consultas bizarras.

Me arrependo amargamente de não ter pedido tempo para convencer meu gerente e treinar minha equipe, o código da camada de persistência era 75% duplicado com buscas que retornavam objetos e grafos parciais dependendo do cliente, montar objetos na mão e demais bizarrices.

Eu usaria Spring há uma ano e meio atrás mas isso porque eu conheci o framework já no primeiro livro do Rod Johnson, realmente não era algo tão popular.

A versão 2 do Hibernate era muito superior à toda a parafernalha de Entity beans e, IMHO, ao TopLink e JDO.

#6

No início do mês colocamos em produção com sucesso um projeto na UFRN com hibernate. É um sistema grande, com mais de 200 tabelas no banco de dados, usar JDBC seria inviável. O hibernate foi essencial. Assim como o Daniel e o Philip, acho que você deveria usar spring e hibernate. Os benefícios de usar hibernate superam e muito os riscos que ele agregaria nesse caso. Não conheço tanto de spring para dar opiniões tão sólidas quanto as deles, mas com o pouco que conheço já dá para ver as vantagens.

#7

Só falta eu começar a adotar Spring nos projetos da casa. É o que nos falta, quando não usamos EJB full, ou mesmo com ele.

#8

eu disse value object mesmo
http://www.allapplabs.com/j2ee_design_patterns/j2ee_design_patterns_transfer_object.htm

#9

pra projetos novos eu tb adotaria, mas na época eu achei que era inviável.

#10

eu optei por jdbc puro pois era exatamente esse o meu caso. Ia ter muito sql e ia ter de ter uma boa performance (precisei fazer tunning em muito sql pra poder conseguir isso). Fiquei com cagaço de, do mesmo modo que no ejb 1, não obter a performance que eu precisava usando algum framework.

Se tivesse optado por usar entitys teria me dado muito mal - o EJBQL já tinha me provado isso no outro projeto (os caras fizeram muita coisa com DAO pq ou não tinha como fazer com entitys ou a performance não era boa.)

#11

Por que vocês usariam Spring, só por curiosidade?
O que ele tem que atende os requisitos do sistema?

#12

Quisera eu poder decidir tudo que meus clientes e patrões vão usar. Isso é uma faca de dois legumes: barra criatividade mas ao mesmo tempo protege o patrimônio dos caras.

Vamos a um exemplo análogo: quem tem aplicação com EJB 3 hoje em PRODUÇÃO? (óbviamente não vale contar trabalho de escola, mestrado, etc). Nenhuma empresa grande, com gerência de risco ativa, deixaria isso a não ser que a vantagem competitiva agregada justificasse as dores de cabeça que qq tecnologia nova traz.

#13

[quote=agodinhost]
eu disse value object mesmo
http://www.allapplabs.com/j2ee_design_patterns/j2ee_design_patterns_transfer_object.htm[/quote]

Eu já contei isso diversas vezes aqui mas lá vai:

A Sun rebatizou este padrão para Transfer Object primeiro porque ele é uma variação de Data Transfer Object e segundo porque Value Object é um padrão de Fowler/Evans:

http://java.sun.com/blueprints/corej2eepatterns/Patterns/TransferObject.html
http://martinfowler.com/eaaCatalog/valueObject.html
http://martinfowler.com/eaaCatalog/dataTransferObject.html

Considerando que oficialmente não foi lançado, você não está querendo um pouco demais não? De qualquer modo o JBoss tem whitepapers de clientes seus utilizando essa arqutietura.

#14

[quote=microfilo]Por que vocês usariam Spring, só por curiosidade?
O que ele tem que atende os requisitos do sistema?[/quote]

  • Gerenciamentod e transações declarativas
  • IoC/DI
  • Integração com EJB
  • Integração com Hibernate
  • Spring MVC
  • AOP
  • Remoting
#15

O que é isso?

Desculpem a ignorancia, mas pensei que isso era IoC e DI. O que mais AOP oferece? (IoC e DI é AOP ???)

O que é isso ?

#16

[quote=pcalcado]- Gerenciamentod e transações declarativas

  • IoC/DI
  • Integração com EJB
  • Integração com Hibernate
  • Spring MVC
  • AOP
  • Remoting
    [/quote]

Nunca usei spring (sou um zero à esquerda nesse assunto de inversão de componentes tb). Como é o suporte? Como é a demanda de profissionais no mercado?

#17

[quote=saoj][quote=pcalcado]

  • Gerenciamentod e transações declarativas

[/quote]

O que é isso?

[/quote]

http://static.springframework.org/spring/docs/1.2.x/reference/transaction.html

http://static.springframework.org/spring/docs/1.2.x/reference/aop.html

http://static.springframework.org/spring/docs/1.2.x/reference/remoting.html

A documentaçãod e referência do Spring é excelente, vale uma lida :wink:

#18

[quote=pcalcado]Considerando que oficialmente não foi lançado, você não está querendo um pouco demais não? De qualquer modo o JBoss tem whitepapers de clientes seus utilizando essa arqutietura.
[/quote]

Não, não estou querendo demais não, desculpe. Foi vc quem disse que usaria o Spring a um ano e meio atrás. Exatamente a mesma situação, IMO.

#19

Vamos comparar as situações.

Spring: Framework Open Source especificado por Rod Johnson em seu livro como Interface21 depois feito livre. Implementação disponível há mais de um ano.

EJB 3.0: Especificação que ainda não foi oficialmente terminada. Apesar de fabricantes já divulgarem previews e beta, teoricamente uma implementação só surge após a especificação ser terminada e então implementada. Nenhuma implementação oficial finalizada disponível até agora.

Fora que eu não falei que usaria Spring porque A, B ou C estavam usando, falei que usaria porque conhecia o framework :wink:

#20

Okay, okay, vc conhecia bem a parada. Mas isso não é o normal. Pelo menos no meu caso o aprendizado é muito, muito lento (meus neurônios já não fazem as sinápses como antigamente, puts).

Eu não encararia, como não encarei entity 1, só isso - principalmente pq não havia apoio algum da gerência usuária. Como já disse não conheço o Spring, conheço superficialmente o Spring MVC.

Cara, o risco de usar ferramentas ou tecnologias novas não é só tecnológico - é pessoal tb. Duvido que vc nunca tenha entrado em algum projeto onde teu gerente tenha lhe dito “Fica calmo, vai dar tudo certo - nossa equipe toda é experiente em struts, em hibernate, etc …” mais daí, qdo vc começa no projeto, logo de cara, tú se da conta do problema: caraca, se eles sabem struts eu sou o papa!!!

Fora a falácia: teu gerênte começa a propagandear que seu projeto está usando x, y ou z e todo mundo logo fica em cima de vc.

Gosto de arriscar, gosto de ferremantas novas, adoro fussar - mas a gerência tem de apoiar.
EDIT: puts, rimou!!! Dá pra fazer um funk!!!