| Autor |
Mensagem |
|
|
Depois que se baixa o projeto, a única obrigatoriedade é a de usar uma versão atual do Java, correto? Fora isso, pode levar quantos anos quiser para terminar o projeto? Baixei o projeto no meio do ano passado e queria saber se ainda posso conclui-lo...
abraços
|
 |
|
|
Olá,
também estou vendendo um voucher com as mesmas características e pelo mesmo preço.
interessados favor enviar um e-mail para: alexandregazola@gmail.com
abraços
|
|
|
|
Olá,
vc é do Rio??
Eu tenho um voucher que vai vencer no final do ano e estou querendo vendê-lo. Se te interessar...
abraços
|
|
|
|
Estórias ( não Histórias (stories =/= histories) )
O vocábulo "estória" entrou em desuso... deve-se utilizar "história" para todos os casos
abs
|
|
|
|
O model é na realidade uma forma de Mediador que traduz informação entre a camada MVC e a camada "abaixo". Essa camada tem um ponto de entrada. Agora sim, um façade ou um serviço ou algo assim. O modelo usa o façade/serviço/etc.., mas ele em si proprio não é um façade/servicço/etc.
Muito boa sua explicação Sérgio... só tenho uma dúvida: é sempre necessário ter um modelo na camada de apresentação do MVC que, então , se encarregará de acessar o domain model/ service layer?? Em alguns casos, esse model vai simplesmente delegar p/ o service layer/façade e, neste caso, não seria melhor o controlador trabalhar diretamente com a interface p/ o service layer? Se sim, neste caso, o próprio service layer faria o papel do modelo MVC, estando assim situado em outra camada.
|
|
|
|
|
O livro do Evans é a principal e quase que única referência sobre DDD... Particularmente, numa primeira leitura de uma parte do livro, não gostei muito não... achei meio abstrato... Vou ver se leio novamente...
|
|
|
|
classes de negocio devem ter somente ter getters/setters e seu construtor
Esse artigo fala um pouco sobre isso: http://fragmental.com.br/wiki/index.php?title=Fantoches
Eu gosto da definição do PoEAA (p. 134) que separa "lógica de negócio" em duas:
- lógica de domínio: componentes que tem a ver apenas com o domínio do problema, implementam as regras de negócio
- lógica de aplicação componentes que tem a ver com a infra-estrutura da aplicação, com a tecnologia
No caso, a camada de serviços e os daos se encaixariam na lógica de aplicação...
abraços
|
|
|
|
Ah, eu não acho legal chamar código do Hibernate diretamente das classes de negócio... o DAO ajuda a isolar o código do Hibernate do código da sua aplicação... Acho mais recomendável, utilizar uma interface conveniente para sua camada de persistência (DAO) e implementar essa interface do jeito que quiser (usando Hibernate ou nao).
Seguem alguns artigos sobre o assunto:
http://www.ibm.com/developerworks/java/library/j-genericdao.html
http://www.ibm.com/developerworks/java/library/j-pop1/
http://www.ibm.com/developerworks/java/library/j-pop2/
abraços
|
|
|
|
Mas muito produtivo e concordo que com portlets não há arquitetura mais conveniente.
Olá,
poderia explicar um pouco quais as vantagens do JSF para desenvolvimento com portlets? Estou trabalhando no projeto de um portal e estamos pensando em utilizar o Flex no front-end com Java no back-end.
abraços
|
|
|
|