| Autor |
Mensagem |
|
|
Leonardo3001, muito interessante essa abordagem.
Apenas surgiu uma dúvida quanto a isso. No caso de uma aplicação utilizando JSF simples, sem EJB, como ficaria essa divisão? No caso no cliente continua tendo a camada de visão e apenas de visão certo? E no servidor ficariam apeas a de controle e de modelo?
Aparentemente ficaria dessa forme e portanto não teria no servidor as 3 camadas.
Esse tópico está ficando interessante...
flw.
|
 |
|
|
Blz?
Não sou nenhum especialista em EJB, mas vou tentar explicar o basico
EJB é uma forma de você criar aplicações distribuídas, onde cada pedaço da aplicação (inclusive a camada de modelo) está em um computador, por exemplo.
No caso o EJB é aplicado na camada de modelo (se não me engano). Em relação a persistência não teria relação direta com o EJB, mas sim a elaboração de uma camada de persistência, comforne o padrão de projeto DAO.
flw...
|
|
|
|
Blz?
V (no cliente) --------------> C e M (no servidor)?
ou
v e C (no cliente) ---------> M (no servidor)?
ou
v e C e M (no cliente -----> Base de dados (no servidor)?
Considero a primeira opção mais interessante no seguinte aspecto:
Controle no cliente pode ser um pouco complicado em relação à máquina do usuário. Em um sistema distribuido, pode ter usuário dom Pentium II com 128 de RAM e com DualCore com 4 Gb de RAM. Portanto para evitar que clientes ocm máquinas antigas tenham problema de processamento e memória acho mais interessante concentrar em servidor o processamento. Outro aspecto fundamental a ser observado é a segurança, que dependendo do sistema pode determinar sua escolha.
Não gosto da solução MVC inteiro no cliente....seria a última que eu adotaria...
Espero ter ajudado..
flw
|
|
|
|
Blz?
Fazer um distema MVC distribuído, mas em que sentido? Cada parte da sua aplicação deve rodar em um servidor diferente? Se for o caso deria EJB (use a versão 3.0).
Em relação a persistência recomendo o Hibernate com JPA. Lembrando que o JPA é apenas um conjunto de interfaces para padronizar o acesso a banco. Embaixo dele vc terá que rodar o Hibernate ou Toplink, por exemplo.
Espero ter ajudado.
|
|
|
|
Blz?
Estou tentando utilizar o certificado do pronova e apresenta o mesmo erro.
Caso alguém tenha idéia do que possa ser avise.
Se eu achar a solução coloco no forum
obrigado,
flw..
|
|
|
|
A Edição 2008 do CONISLI trará um ciclo de palestras e oficinas sobre Business Intelligence (BI).
A programação desse ciclo é a seguinte:
Dia 18/09
09:00 às 10:15: Demonstração da Plataforma Pentaho, Auditório Sérgio Amadeu.
13:00 às 15:00: ETL com Pentaho Data Integration, Laboratório Júlio Neves.
15:00 às 17:00: Criando Relatórios Ad Hoc com Pentaho, Laboratório Júlio Neves.
Dia 19/09
9:00 às 11:00: Criando Cubos OLAP com Schema Workbench, Laboratório Júlio Neves.
Tarde: Anúncio do Novo Portal Pentaho Brasil
Palestra Business Intelligence com Software Livre: Pentaho BI Suite
|
|
|
|
Valeu! Vou ver a documentação para ver se atende.
t+
|
|
|
|
Não vale como obrigação. Acredito que essa discussão será inútil, já que você acha que o que falam aqui (com todo o respeito às pessoas, inclusive o CV, que sugerem as soluções) sere como auxílio não como obrigação, quem vai desenvolver que tem que assumir a responsabilidade, ok?
E novamente, se mudar os requisitos, de forma que dobre o esforço, custo e prazo da aplicação, como vc vai provar para o cliente que isso é uma verdade? como irá discutir regras de negócio com o cliente se não tem uma forma de comunicação e documentação do que vai ocorrer no sistema?
Onde trabalho documentamos os sistemas e a documentação ajuda muito no sentido de evitar entendimentos errados e implementarmos errado. Isso é essencial.
Também trabalho com sistemas grandes, e pelo sistema ser grande que devemos atentar para a documentação de requisitos. Acredite, é mais importante do que você imagina.
O RUP indica que é necessário sim a documentação de requisitos, inclusve no CMMI é indicado como prática específica a aprovação dos requisitos pelo cliente.
OBS: o processo de desenvolvimento organizado é importante, não podemos deixar conhecimento na cabeça das pessoas, o desenvolvimento de sistema deve ter realizado de forma a deixar todo o conhecimento do sistema documentado....ainda mais os requisitos.
Agora se não conseguiu realizar a implementação a partir de uma documentação organizada, acho que o problema não é na documentação, certo?
Não responderei mais mensagens relacionadas a este tópico visto que não está sendo de ajuda.
|
|
|
|
Blz?
conheço deficientes visuais que são programadores e estão interessados em desenvolvimento em java. Gostaria de saber se alguém sabe que ferramentas para desenvolvimento de java podem ser utilizadas juntamente com ferramentas que fazem a leutira da IDE para o desenvolvedor que é deficiente visual. Não achei nada por aqui e gostaria de uma ajuda da comunidade.
Valeu!
|
|
|
|
Em relação ao comentário do cmilfont, ninguém me manda fazer nada, ok?... ele pode ter sugerido...
Em relação ao comentário do CV....acho que vai ser uma longa discussão...rs...enfim...vamos lá...
Para que se esti e um custo de acordo com o projeto cé necessário sim que se levante um escopo inicial, o cliente não quer jogar dinheiro pela janela...ele quer saber exatamente o que está comprando. Existem cliente que também não pode pagar muito, e dessa forma, através de priorização de requisitos documentados podemos estabelacer um melhor desenvolvimento do sistema.
Por isso ainda defendo a idéia de que é melhor primeiro definirmos requisitos antes de implementar. A não ser que seu cliente não seja muito exigente. Mas aqui precisamos comprovar o custo de cada alteração mínima que vamos realizar.
OBS: é perigoso brincar com o custo do projeto...o cliente pode não gostar...rs....
|
|
|
|
Valeu pela ajuda, mas no caso gostaríamos de um componente que gerassa arquivos ppt em formato de office 97/2000
alguma idéia?
|
|
|
|
Blz, pessoal?
Gostaria de sugestões para componentes para geração de relatórios em powerpoint. Pelo que vi no IReport ele não cria , certo?
Aguardo sugestões.
Obrigado,
|
|
|
|
Blz?
Em se tratando de postgresql, verificar os nomes dos campos de acordo com o banco de dados, pois para o postgreSQL é case sensitive.
T+
|
|
|
|
Blz?
Provavelmente está tentando usar uma variável nula, lembrando que o Hibernate sempre trabalha com objetos, nunca com variáveis primitivas. Verifique se está usando int e troque pela classe Integer, por exemplo. Em alguns sistemas que dei manutenção essa alteração resolveu.
|
|
|
|
Blz?
Em relação a resposta do CV
O proprio ato de desenvolver o software altera seus requisitos (ja tentou usar um termometro comum numa gota d'agua? Mesma coisa). Entao, pq tentar bolar um jeito de fazer com que os requisitos nao se alterem, ao inves de simplesmente estar bem preparado pra essas alteracoes quando elas vierem?
Acredito que não tenha me explicado direito. O problema não é alterar os requisitos, mas sim controlar as alterações e cobrar o custo dessas alterações para o cliente. Apenas identificando quais requisitos foram alterados após o fechamento de um escopo inicial podemos identificar essa mudança e, aplicando a APF identificar o novo custo e prazo do projeto.
Em relação ao Pair Programming concordo com vc, porém nem todas as empresas entendem a facilidade de uso dessa técnica.
E em relação a usar a suite de testes, serve apenas para implementações já realizadas. O ideal é primeiro definirmos os requisitos do projeto para depois implementar, ok? Além disso o cliente não conseguiria entender o que foi mudado através de rotinas de teste e é de fundamental importância deixar claro para o cliente quais as alterações das funcionalidades serão necessárias.
A questão não é deixar de alterar o requisito, mas sim controlar quais alterações estão sendo realizadas e documentar de forma mais adequada para o entendimento de analistas de negócio e cliente.
|
|
|
|