| Autor |
Mensagem |
|
|
|
Em relação a parte web, principalmente no uso de JSF, eu detesto os "pré-moldados" herdados do Studio Creator. Gerar aquela estrutura poluída de ManagedBeans para as páginas, configurações de dataProvider para as tables, toda a sujerada "RAD" nos Backing-Beans... irgh!
|
 |
|
|
emerleite wrote:
Lezinho wrote:
emerleite wrote:Exemplos ?
Um exemplo mais simples e direto de como pode comprometer seu objeto Entity de negócio inserindo diretamente EntityManager, é na construção de testes unitários.
Considerando que EntityManager é uma interface, não vi diferença em coloca-lo no lugar do Repositório para a questão dos testes já que seria possível criar um mock da mesma forma. Não entendi muito bem o seu exemplo.
Com o EntityManager injetado (mock ou não), você teria na mesma lógica espalhado no seu código possíveis ejbqls/HibernateCriterias/Specifications/nativeSQLs ou no melhor dos casos invocações de NamedQueries... tudo junto com o resto de sua lógica.
Ao realizar os unitTests você vai querer testar apenas o pertinente ao método, ou seja, toda a parafernália da persistência vai estar lá no seu design porém ignorada por uso de Mocks.
Isso tudo funciona, mas a fluência do código vai ficar péssima... TDD nisso vai dar dor de cabeça.
O ganho de uma abstração maior, englobando todos os aspectos da persistencia, é evidente.
|
|
|
|
emerleite wrote:Exemplos ?
Um exemplo mais simples e direto de como pode comprometer seu objeto Entity de negócio inserindo diretamente EntityManager, é na construção de testes unitários.
|
|
|
|
Camada de visão e aplicação não é domínio, portanto de nada tem haver com DDD. Pode usar EntityManager, Session, SQL direto na página via JSTL ... Eu quando tenho CRUD simples sem intervenção do negócio não escrevo uma linha de código java, utilizo o DAO declarativo do Seam.
Mas tudo isso, de nada tem haver com DDD ... [2]
|
|
|
|
O seu repositório pode cuidar de operações mais complexas do que simplesmente fazer um CRUD ou uma busca simples. Para formar um agregado, por exemplo, você pode realizar mais de uma consulta no banco.
Um repositório é um elemento ativo no negócio e na modelagem, não é uma ferramenta de acesso a dados. Ele pode ser modelado com comportamento (métodos) que fazem sentido quando colocados em um diagrama do domínio, pois o objeto em sí pertence ao domínio. Um EntityManager não pertence a domínio algum, e seus métodos não são Ubiquitous.
O repositório tbm é um bom lugar para você definir seus contratos quando se interage com algo da persistencia (e retornar uma exception para seu cliente da camada). Isso parece melhor do que retornar true/false, null, 1/0, e outras bizarrices.
Colocar EntityManager diretamente nas entidades parece um grande acoplamento entre meios de persistencia e objetos de negócio.
|
|
|
|
Perdão, me precipitei. Este fix do Europa ainda não vem nos releases:
https://bugs.eclipse.org/bugs/show_bug.cgi?id=203325
Na minha máquina não estou tendo problemas com PermSize, mas se alguém que esteja passando por isso quiser aplicar o fix e dizer se teve resultados positivos, seria interessante.
[]s
|
|
|
|
Na pratica Jonatas, para o desenvolvedor tanto faz se ele é uma emenda para o JSF ou não, o que vemos é a praticidade, facilidade e elegância do código ao se desenvolver com o Seam. O próprio JSF ja foi uma ótima sacada da Sun, não vejo mal na sua utilização.
Eu não sou pretensioso em afirmar que o Seam NUNCA vai ser totalmente independente do JSF (na verdade ele ja é)... ou que cada vez vai ser mais bugado e etc. Pra mim o que interessa é ele resolver os meus problemas e dos clientes do software final, o que ele faz perfeitamente.
jonatasw wrote:No entanto, existe um acoplamento lógico.
Se você está retornando "sucesso", "falha", obviamente você está pensando em presentation layer
Você nao precisa retornar String alguma, como ja disse no post anterior. Você decide o fluxo através de um flow xml, facinho.
jonatasw wrote: Se eu tenho um WebService que utiliza SLSB e este retorna qualquer coisa que não seja pertinente, já é uma quebra de conceito.
WebServices no Seam sao Componentes que utilizam Façades de outros componentes (podendo ser EJB ou não). Nao possui nada de lógica da camada de aplicação.
|
|
|
|
darkseid wrote:Tbm tava usando o beta 2 e vivo com problemas de PermSize. Mesmo fazendo o -XX:MaxPermSize=196M ainda da uns pepinos. Espero q tenham resolvido isso no RC1, que alias, ja estou baixando.
Vlw pela dica!
Na verdade o bug de Permsize, mesmo aumentando o parametro, é um bug do Europa em sua primeira versão. O RC1 esta com a versão atualizada do Europa com o fix para a correção.
Agora me sobra elogios ao JBoss 4.2. Da-lhe redeploy e nada de Out-of-memory...
|
|
|
|
Não foi só o NetBeans que nesta semana anunciou o Release Candidate de sua ultima versão, a Red Hat arregaçou as mangas e disponibilizou o RC1 de sua plataforma de desenvolvimento JavaEE baseada no Eclipse.
Entre as novidades, a nova versão possui:
- Integração total com o Seam 2
- HQL code completation e sintax highlight para as queries
- Lista ordenada de entidades mapeadas na perspectiva do Hibernate (era terrível ter que caçar as classes no Hibernate Tools)
- Tree para configurações do Seam Component e autocompletation para pages.xml
- mini jmx-console para administração do JBoss
- integração de "fábrica" com RichFaces e Ajax4JSF
... além da correção de bugs.
Resumidamente, as ferramentas JBoss (Seam, JBPM, Hibernate, ...) + Exadel + Europa estão integradas e prontas para o consumo (ou se candidatando para ele, hehe).
A versão do Eclipse é a 3.3.1_r3
Download:
http://www.redhat.com/developers/rhds/index.html
|
|
|
|
Para mim a parte mais difícil de se lidar com DDD é definir o real Core of Domain (capítulo do Evans).
Em um sistema grande, onde o usuário final pode interagir com diferentes parâmetros da aplicação que modifica os comportamentos das entidades... a fronteira entre aplicação e domínio, é muito tênue.
|
|
|
|
A assinatura de um método em DDD tem que dizer seu propósito, independente da infraestrura.
Se para isso for necessário passar um objeto populado que assim seja. Se para o negócio é mais claro tipo simples, tudo bem também.
Só não concordo em pensar:
cmoscoso wrote:Sera mesmo que todos esses parametros sao necessários para apenas persistir o entity, ou seja, cria-lo no seu sistema? (geralmente vc precisa apenas de identificadores pra isso)
... quem armazena informações no DDD são os Repositories. Eles não armazenam ou coletam identificadores, eles trabalham com Entities.
|
|
|
|
jonataswingeter wrote:...Vi um tempo atrás um artigo do Gaving falando sobre a possível integração com outros frameworks, além de JSF. Mas até agora a única coisa que percebi que o Seam é realmente uma Emenda para resolver os problemas do JSF(...)
O Seam 2 é independente do webframework em seu core. A equipe do Seam faz a prova do conceito com sua integração totalmente independente do JSF com o GWT, em seu tutorial.
http://in.relation.to/Bloggers/WhatsNewInSeam2 (Removing the JSF dependency)
Escopo de conversação, manter estado entre popups e abas de web browsers, gerenciar comportamento quando o usuário utiliza o "back" do navegador e tantos outros recursos não são meramente "emendas" para o JSF, mas sim soluções para qualquer framework web.
jonataswingeter wrote:
Sobre a possibilidade do EJB3 ter POJO, isso não tira a possibilidade do programador de injetar regras de navegação do JSF no POJO, fazendo um acoplamento. Se eu quiser trabalhar com Binding dos componentes no JSF...vou colocar no EJB ou vou usar uma técnica diferente?
Você não precisa colocar regras de navegação em classes java. No arquivo pages.xml do Seam você pode colocar regras que associam um determinado método da classe Java com seu sucesso de execução ou não. Se o método foi executado com sucesso você é redirecionado para uma página, caso ocorra uma "determinada" exceção você decide no xml qual fluxo seguir. Mas vc tbm pode como JSF, retornar uma String contendo um alias.
Um método de Services retornar uma String não é acoplamento algum, mas se você não deseja isso para sua arquitetura você pode optar por não utilizar EJB no primeiro nível de componentes Seam, e isso tbm responde sua questão sobre fazer bindigs de componentes. O Seam não obriga você usar EJB, um componente Seam é um POJO, que pode ou não ser Remote. Você pode ter um POJO normal atuando para bindings e utilizar uma Façade injetada pelo próprio Seam para isolar sua lógica se você assim preferir.
|
|
|
|
rodrigoy wrote:
Lezinho, a sua aplicação manda mails usando Facelets como o manual diz?
Em servidores SMTP com autenticação segura (SSL ou TLS) as versões do Seam 1.2.1 e anteriores funcionam. Porém, para ambientes onde o protocolo não é seguro, existe um bug (se você especifica ssl = false ele tenta se conectar por TLS). Por esse problema eu já passei...
Felizmente tem um simples fix para isso na versão 2.0.0:
http://jira.jboss.com/jira/browse/JBSEAM-1795;jsessionid=F87B53058681F54E96E6F96F775F9CEC?page=all
Quanto ao problema que você relatou de ter componente JSF nas tags facelets gerando algum erro, aqui não tenho esse problema, funciona normalmente (minhas configurações do Seam são baseadas no Red Hat Developer Studio, não no seam-gen).
Aliás, saiu o RC1 do RHDS com suporte ao Seam 2 
ddduran wrote:
Só uma pergunta de ignorante, independencia de JSF?
o Seam não vai ser mais uma implementação da especificação?
Na verdade ele nunca foi uma implementação da especificação. Sempre foi necessário você ter os jars da implementação jsf (r.i. ou myfaces) para trabalhar com o Seam. As características e funcionalidades do Seam não são as mesmas do JSF.
|
|
|
|
Estou com um questionamento parecido com o seu Rodrigo. Vou optar por manter o desenvolvimento no 1.2.1 GA e fazer testes paralelo com o 2.0.0 GA.
Se for trocar neste momento e surgir complicações, a data para nosso release poderá ser comprometida. Mas se com os testes eu me der bem, em Dezembro farei a migração.
Conforme eu for realizando os testes vou postando aqui.
|
|
|
|
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.
|
|
|
|