| Autor |
Mensagem |
|
|
O seu "outroVO" esta nulo em uma das fases do clico de vida. Então dá NullPointer e o conversor joga valor inválido.
Faça um log.info ou debug em trechos do seu código e veja se o problelma é realmente esse. Se for, o problema é o mesmo que eu tive e o saveState do tomahawk pode te ajudar.
|
 |
|
|
A nova versão do JBoss Seam esta disponível para download com muita coisa boa.
Agora independente de vez do JSF em seu core... integrações com Quartz, JfreeChart... possibilidade de criação de componentes Seam com Groovy entre outras features:
http://in.relation.to/Bloggers/WhatsNewInSeam2
download:
http://labs.jboss.com/jbossseam/download/
docs:
http://docs.jboss.org/seam/2.0.0.GA/reference/en/html/index.html
|
|
|
|
|
mfp.c, isso nao é herança multipla.
|
|
|
|
Java não suporta Herança Multipla nativamente.
|
|
|
|
Para começar legal na web, eu recomendaria JSF (JavaServer Faces).
O Struts em sua versão 1.x pode ser bastante utilizado ainda hoje, mas é absolutamente ultrapassado, enfadonho e ineficiente para o que se exige hoje em dia de um framework para web.
Além disso, sua curva de aprendizado com JSF é bem menor. Vale também mencionar que ele é uma especificação do próprio JavaEE para framework web.
Para persistência, eu recomendo vc usar Hibernate sim, mas como implementação da JavaPersistence API (JPA), e não hibernate puro.
Pesquise mais sobre JSF e JPA.
OBS: Quando você estiver um pouco mais avançado com o JSF, vocë pode partir para o JBoss Seam 
|
|
|
|
Não é boato não Fabio, vai ter mesmo.
Por isso pessoal, o negócio é chegar cedo para estacionar o carro (aquilo ali vai estar caótico).
|
|
|
|
fmeyer wrote:Eu estarei la palestrando. Sobre ANTLR, DSLs e vou falar um pouco do mvel e do drools
É Felipe, sua palestra é uma das que mais me chamou atenção. Presença obrigatória !!!
Como vai ser o formato da oficina do arquiteto? Discussões abertas?
Até sexta e sábado pessoal ...
|
|
|
|
|
Yeah ...
|
|
|
|
Olá ...
Sua idéia esta correta. Não coloque regras de negócio em seus Backing Beans pois desta forma você deixa seu sistema pouco reutilizável e até mesmo pouco escalável. Prefira sempre delegar isso a outra camada, para evitar acomplamento desnecessário (vc poderia reutilizar as chamadas a objetos de negócios em WebServices, RichClient Swing, etc).
|
|
|
|
BiraBoy wrote:Cara, é que pelo que tenho lido (nas lidas saltadas do livro do Evans e dos artigos de Shoes) eu entendi que Service é conceito de domínio e portanto deve ser desacoplado de tecnologia.
O que raciocinei é que o ApplicationLayer seria o equivalente do ServiceLayer do Fowler(...)
Nos tempos de EJB 3.0, os objetos são POJOs. Portanto uma Session Façade pode ser um Service, exposto por sua interface, que mesmo assim não fere o conceito de Service de Evans, assim como tbm obedece os preceitos do Fowler.
Como citei no trecho do Quicky, Service é uma técnica que o DDD utiliza, mas que ja é antiga é usada pela maioria dos frameworks (não sou eu quem disse isso, é o texto).
|
|
|
|
O diagrama anexo de Fowler, mostra um Service de Lançamento de receitas (Revenue Recognition).
Tal Service (RecognitionService), que Fowler coloca na descrição como sendo um possível Stateless Session Bean, herda funcionalidades de um Application Service responsável por serviços de infraestrutura (por isso este outro é um Service de aplicação).
O RecognitionService não executa lógica de negócio, mas referencia objetos do domínio que as contém, possívelmente Entitys. Por isso também implementa o padrão Service do DDD, que agrupa um conjunto de funcionalidades (expostos por uma interface) em um determinado objeto (os Services) que delega as atividades para objetos de domínio.
O Service pode ser invocado pela Camada de Aplicação, por um ManagedBean do JSF, Action do Struts, etc, como sendo uma Façade. No Domain Driven Design Quicky, de Avram e Marinescu, eles mencionam que os próprios Frameworks implementam Services:
Domain Driven Design-Quicky wrote:Services act as interfaces which provide operations. Services are
common in technical frameworks, but they can be used in the
domain layer too.
[]s
|
|
|
|
|
Você pode implementar em uma Service Layer do Fowler um Service do Evans. Se Evans diz que uma Service é um ponto de junção de várias classes de negócio para um determinado propósito e a Service layer de Fowler é a fronteira entre a aplicação e o negócio, ambos padrões podem ser co-relacionados.
|
|
|
|
Bom, deixando suas observações pessoais de canto (pq em meu pé quem pega é a minha namorada), vamos lá:
cmoscoso wrote:Você não percebe mas a complicação está no fato de você não conseguir explicar com clareza a diferença entre a camada Service e Application. Talvez porque não haja
Talvez VOCÊ não percebeu que não sou eu que menciona sobre as diferenças, mas sim os próprios autores, como no texto que citei no post anterior. Aliás vale repetir a citação:
Domain Driven Design wrote:
"While using Services, is important to keep the domain layer
isolated. It is easy to get confused between Services which
belong to the domain layer, and those belonging to the
infrastructure. There can also be Services in the application layer
which adds a supplementary level of complexity."
... pra mim esta bem clara e nítida a existência entre Services de infraestrutura, pertencentes a camada de aplicação, e os services pertencentes a camada de domínio, aqueles que se relacionam com um caso de uso. Detalhe, o trecho acima trata de Services no capítulo destinado a Services em um livro de DDD, portanto são Services do DDD. Não há falta de contextualização.
Com base no trecho acima, olhe no diagrama de classe que Fowler colocou no PoEAA (a qualidade ficou péssima, mas acho que você vai conseguir visualizar as classes), que esta anexada com este post. Lá esta descrito um modelo exatamente como na citação, um service para o negócio e um para a infraestrutura da aplicação.
cmoscoso wrote:
(...) e vc se justifica colando citações sem contexto do seu autor preferido.
Fora do contexto? São trechos totalmente pertinentes a suas colocações, vindas de autores como Martin Fowler, Eric Vans, Floyd Marinescu... Se estas pessoas não são boas referências, então realmente estou mal embasado.
cmoscoso wrote:
Eu considero as camadas Service e Application como a mesma e não sinto falta de outra camada.
Pense que existem pessoas que estão interessadas em comecar a aplicar práticas mais modernas para projeto de software OO e precisam competir com as arquiteturas de referência estabelecidas. Eu não vejo como essa camada adicional pode ajudar essas pessoas a melhor organizar sua arquitetura usando apenas o seu argumento de que tem que ser assim porque o mestre mandou.
Se você não sente falta, não utiliza. Nenhum destes autores citados dizem que você DEVE usar um Service voltado para os serviços de aplicação, ou um como ponte para os objetos de domínio. Você usa conforme sua necessidade. Toda camada é "adicional", você usa se sente necessidade de usá-la.
|
|
|
|
Aiaiai ...
Services são Services. Existem de aplicação e de negócio, não sei onde esta a complicação disso. Tanto o DDD quanto o PoEAA comentam dos dois.
De fato Phillip, a discussão era de Manga e já estamos falando de Banana.
|
|
|
|
"Client Layer"?
Client Layer é qualquer camada que faça uso de outra camada, ou seja, uma camada cliente da outra... isto sim não é Padrão. Praticamente todos diagramas DDD envolve "Client"s que representam tais camadas.
Um repositório pode ser client de um DAo, uma Entity pode ser cliente de um VO, um Aggregate pode ser client de um Entity ...
"Camada de aplicação" é aquela relevante ao contexto da aplicação (ManagedBeans, Actions) ou aquelas que server como uma Supercamada para a de Serviços, oferecendo suporte como de email, ftp, etc (de nada tem haver com o negócio).
No livro de Fowler você vê Service direcionados ao negócio, que faz o workflow aos entities e VOs, e aqueles definidos como seu supertipo para suporte a serviços da aplicação.
Na própia citação que você coloca, é definido o Service como uma fronteira entre a aplicação e o Domínio.
No DDD isso não muda, podendo existir tanto Service voltado a negócio como para Aplicação:
Domain Driven Design wrote:"While using Services, is important to keep the domain layer
isolated. It is easy to get confused between services which
belong to the domain layer, and those belonging to the
infrastructure. There can also be services in the application layer
which adds a supplementary level of complexity."
O texto em negrito do DDD é praticamente o mesmo do PoEAA.
|
|
|
|