| Autor |
Mensagem |
|
|
pcalcado wrote:
Se falarmos simplesmente de objetos tudo é sempre persistente. Persistência como conhecemos em TI (bancos de dados, xml, etc.) é apenas uma alternativa à limitação que é não podermos ter objetos sempre em memória.
Ok partindo dessa premissa a persistencia é algo q deve ser o mais tranparente possível certo? Ao ponto que isso não deveria estar refletido no meu domain model.
pcalcado wrote:
Partindo deste ponto, um sistema que leve OO a sério vai tratar todos os objetos como se eles fossem permanentes sempre, por isso coisas como 'atualizar' são desnecessárias conceitualmente. Apagar é uma exceção porque apagar é eliminar todas as referências um objeto e isso não é simples, mas vamos passar essa por enquanto.
Então basicamente um repositório que isola a persistencia tem um método para criar (e algumas variantes) e métodos de busca.
pcalcado wrote:
Se você puder escolher, use um frameworkde ORM como JPA ou Hibernate. Estes vão permitir que você abstraia isso e cuidam e atualizar objetos quando transações se encerram.
Dessa forma o correto seria modelar o domain model sem se preocupar com persistencia, já q ela é uma constante e nesse caso o repositório terá de se virar e ir acrescentando a ele métodos para busca específicas (ou usar os métodos genéricos até onde der).
E apenas depois quebrar a cabeça para persistir isso de forma eficiente, ainda mais qdo algumas modelagens onde tem um objeto em várias tabelas e vice-versa.
As perguntas são pq eu vejo muito as pessoas modelando DAOs e objetos de negócio e sempre se preocupando com o banco de dados e as tabelas, sim é uma preocupação relevante, mas num domain model ela deveria ser secundária e vir depois, ou será q estou confundindo tudo e estou errado aqui?
|
 |
|
|
Humm, entendi, eu interpretei como se vc tivesse vários DAOFactory um para cada forma de persistencia. Você concentra tudo num único DAOFactory q le esses parâmetros e assim ele sabe qual DAO usar (Hibernate ou JDBC, ou etc), é bem isso que eu precisava, estava quebrando a cabeça, ... Valeu.
|
|
|
|
danieldestro wrote:Assim como eu tenho PessoaJdbcDAO, eu posso ter PessoaHibernateDAO. Mas é um OU outro. Mesmo assim você pode misturar os dois ali dentro de uma implementação, sem problemas.
Sim até aí tranquilo.
Mas o seu factory ou cria objetos JDBCDao ou HibernateDao, por isso e é por isso q é fácil mudar entre um e outro é só mudar a factory.
No meu caso eu queria q qdo eu chamasse determinados métodos ele usasse outra factory, qual a melhor maneira de fazer isso, se é viável, ou estou complicado e deveria fazer na mão mesmo.
O motivo para essa complicação, é q eu gostaria q no código mesmo ficasse transparente qual a DAO factory q está sendo usada e em algum lugar eu definiria isso. Depois se eu conseguisse reproduzir com hibernate a mesma performance dos casos mais complexos eu mudaria as configurações e não precisaria mexer no resto.
|
|
|
|
danieldestro wrote:
Com este mecanismo fica MUITO fácil trocar de JDBC pra Hibernate ou qq outra implementação que você faça, até mesmo híbrido, como eu uso aqui, já que é tudo baseado nas interfaces. Aí é só fazer um mecanismo de configurações e voilá!
Eu uso essa mesma abordagem, mas gostaria de saber como vc faz para fazer esta parte híbrida JDBC + Hibernate. Como não posso mexer no banco e resolvi fazer o modelo de classes mais voltado a OO, acabei ficando com alguns pepinos para fazer a parte hibernate, então uma abordagem híbrida seria o ideal para mim, qq sugestão é bem vinda.
|
|
|
|
Depois de ler e pesquisar um pouco sobre integração contínua, estou querendo aplicá-la num projeto pequeno de testes para ver algumas práticas e ganhar mais conhecimento prático.
Vi os artigos sobre JUnit (JM32, MJ17) e Integração Contínua (JM35), entre outros pela internet e gostaria de algumas sugestões sobre o que é importante e necessário, o q é interessante e principalmente o que é dispensável num ambiente desses.
- IDE: Eclipse
- Teste: JUnit
- Building: Ant
- SCM: Subversion
- Code coverage: Emma
- Code Analysis: PMD
- Issue e Bug Tracking: Bugzilla
|
|
|
|
Ainda existe uma terceira situação.
Também fiz federal a proposta do curso era uma mistura de análise de sistemas com engenharia e com administração, no final você não via nenhuma das tres áreas de forma satisfatória, quando estava no último período mudaram a grade curricular e melhorou bastante, mas não pude me beneficiar disso, mas a questão é que a faculdade não tinha recursos para manter dois cursos de informática. As aulas de Economia (tive um ano de macro e micro economia) realmente não interessavam a maioria dos alunos e os próprios professoros sabiam que ninguem ali estava muito interessado.
Ou seja resumindo, por mais interessado que esteja posso não estar não especificamente numa ou outra matéria ainda mais numa que está totalmente fora do escopo do curso, e que está nele devido a uma aberração do currículo. Nesse caso eu com certeza utilizaria outros meios para passar caso o professor implicasse e não tivesse noção que ninguém ali está interessado.
|
|
|
|
Tem o Koders
http://www.koders.com/
|
|
|
|
Sim, será linux, com certeza sem interface gráfica, nenhuma ide instalada.
A máquina que vou colocar será um PIV-3Ghz, 1Gb de memória, com 2 HD de 80Gb (7200RPM SMB SATA II).
Com certeza ela aguenta um site, a questão é quantos sites simultâneos, com a especificação que eu passei acima, ela aguentaria, alguem teria uma idéia?
|
|
|
|
Eu acredito que por muito e muito tempo.
Ao mesmo tempo que o número de profissionais aumenta, o volume de trabalho e de projetos também aumenta. Outro ponto é que vários países chegam a importar bons profissionais, se países que tem uma estrutura educacional e tecnológica mais sólida que o brasil importam, por aqui ainda existe muito mercado.
O que pode acontecer é o mercado começar a querer mais um determinado tipo de profissional ou metodologia, ou sei lá o que, aí java pode ser que perca mercado (no caso de outra linguagem ser melhor), mas por outro lado nada impede que a própria linguagem mude e acompanhe estas mudanças.
E por último tem muita coisa que foi feita e migrada para java, mesmo que apareçam novas linguagens, vai existir muito código para dar manutenção o pessoal de cobol que o diga, conheço vários que trabalham apenas com isso e várias empresas que não pensam em mudar seus sistemas de cobol (algumas inclusive procuram integrar cobol com java).
|
|
|
|
Risos, thingol, vc está certíssimo, simplifiquei demais a pergunta, espero q os dados possam ajudar:
** "Apenas Java e Postgres"
Basicamante, Java, apache, tomcat, postgres, as bases não são grandes as maiores tables terão uns 30.000 itens, sem contar as de log, mas estas periodicamente serão exporadas para um sistema interno afim de elaborar alguns relatórios
** Que tipo de sistema e que tecnologia vai ser usada (portal, EJB etc.);
Sem EJB, acredito que o volume não compensa, possivelmente será feito usando mentawai + framework de template (ainda pesquisando);
E aqui vem uma dúvida que eu sempre tive, sempre vejo muitos falando de EJB, muitos querem aprender, considero devido a uma exigencia de mercado, e muitos falam q EJB deveria ser usado apenas em projetos grandes, mas o que seria um projeto grande que necessitasse usar EJB?
** Quantos clientes vão estar conectados simultaneamente;
No momento isso é no chute as previsões indicam picos de 100 clientes em cada um dos sites, ou seja 400 clientes simultâneos, mas é uma previsão supeestimada para esse início, mas cada conexão é rápida, na maioria dos casos não será necessário armazenar grandes dados em sessão.
** Se o sistema é só para acesso online simples, ou se tem um monte de relatórios gerenciais e outras coisas que gastam máquina;
Acesso simples, relatórios gerenciais rodaram numa máquina interna
** Se ela tem de ficar ligada 24x7 ou se o site pode ficar parado à noite (funciona das 8 às 17 h);
Fulltime, mas com maior carga na horário comercial
** Tempo de acesso esperado;
Rápido, pois o cliente é o usuário final
** e o que puder extrair de informação...
Foi considerado usar um provedor externo, mas eu posso livre acesso a um provedor, contudo eles não oferecem hospedagem java, então estaria montando essa máquina só para atender esses clientes. Além da facilidade de configuração.
|
|
|
|
|
Estou precisando dimensionar uma máquina para servir de servidor, rodará apenas java e postgres, serão 4 sites JEE. Alguem tem ideias de configuração, ou onde eu poderia conseguir os parâmetros para dimensionar?
|
|
|
|
Duas dúvidas:
1. Qual a diferença conceitual entre o Service e o Facade, ali quando é apresentado o GerenteConta como um Service, ele não poderia ser tb um Facede por definir um ponto de entrada?
2. Acredito que entendi o conceito do Repositório, mas fiquei um pouco perdido em como viabiliza-lo, e quem é responsável pelo o que: Usando o exemplo da revista, eu tenho um repositório de categorias, quem é responsável por criar este repositório, seria a Facade? A Facade busca uma categoria no repositório, se não encontrar, o repositório busca no DAO? E ao criar uma nova categoria, primeiro coloca ela no repositório e é ele o responsável por salvar fisicamente (usando o DAO).
[]s
|
|
|
|
nefertiti wrote:
scottys0 wrote:Blz ... vc ignora a mulher e vira corno ... pq em um mes de copa nem todos os ricardoes gostam da selecao 
Certíssimo...  !!...Homens, depois não reclamem!!!!!
Nessas horas que eu fico feliz por não gostar de futebol, risos !!!!
|
|
|
|
Replicar os dados tem outro problema, não sei as necessidades, mas replicando vc não terá uma visão online do sistema de e-commerce, isso pode ser um problema.
Já acessando os mesmos dados, usando hibernate, cache, etc, tem o problema de dados inconsistentes, mas acredito que deve ter algo para ajudar isso, também estou curioso.
|
|
|
|
Fabrício Cozer Martins wrote:
Edufa wrote:Mas por outro lado essa grande variedade de soluções intimida um pouco o iniciante.
será ? e opção de escolha ? não favorece ?
Com certeza, eu prefiro ter 20 opções de fazer uma coisa do que apenas duas, mas para quem está começando, ter 20 opções na prateleira intimida, ainda mais que algumas são parecidas, outras falta documentação e umas não se aplicar ao negócio, mas ele só vai descobrir testando.
|
|
|
|
|
|