| Autor |
Mensagem |
|
|
|
Isso é muito relativo e depende dos requisitos do sistema a ser construído.
|
 |
|
|
sergiotaborda wrote:
O DDD é uma ideia boa ,mas apenas para modelagem do dominio. Quando chega na parte de implementar isso na prática com tecnologias reais e requistos não funcionais poderosos como distribuição o DDD começa a ser um problema como podemos ver pela quantidade de post sobre como implementar Repository ou como gravar um Entity no banco. São duas esferas diferentes.
Não concordo totalmente com isso, justamente pq domínio e infraestrutura são esferas diferentes.
Quer distribuir objetos, ótimo, utilize Session Façades e preserve seu domínio. A(s) entidade(s) rica(s) podem inclusive pertencer como atributos destes beans em um modelo Stateful e terem seus estados mantidos e distribuidos em várias requisições.
Não vejo onde Domain-Driven influencia na distribuição de um sistema.
|
|
|
|
saoj wrote:Uma dica:
Mudar o título de Desenvolvimento Web para "Desenvolvimento/Frameworks Web"
Por que?
Muita gente posta coisas de frameworks web no forum "Ferramentas, Frameworks e Utilitários"
"Framework" em Java é uma palavra muito genérica!
Concordo com o Sérgio.
A seção de web e frameworks sempre é uma confusão de tópicos.
|
|
|
|
Estamos em processo de desenvolvimento do ambiente de testes com o Seam, Rodrigo. Atualmente, pra valer mesmo, apenas jUnit4.3, EasyMock e DBUnit estão bem definidos (que na verdade já era definido antes).
Desconsiderei o TestNG (que seria a escolha mais obvia por sua integraçao com o Seam), pq sua escolha seria atrelada aos testes de integração com o JbossMC, o que não estou fazendo por conta dos Bugs que citei. Portanto não teria ganho nenhum e optei por continuar com o JUnit.
Estou avaliando executar integração Contínua com o Cruise Control, com algum plugin Fit para Wiki e aceitação (possívelmente o Fitnesse) mas ainda não esta no ambiente.
O Selenium vai entrar no plano de testes com a interface do usuário, estabelecendo o final da integração.
Meu sprint esta cheio, e até agora a integração não esta pronta no ambiente por falta de tempo e dedicação... pelo menos ainda resta os unitários ...
|
|
|
|
Olá Rodrigo ...
Usando TDD, é possível modelar como deve ser o comportamento de suas "Unit of Works" com base somente nos unitários, correto? Não bastaria você utilizar um Selenium da vida para os testes de integração/aceitação depois de aplicado os unitários e feito o código funcional?
Eu deixei de utilizar o JBossMicrocontainer por alguns bugs eternos do Jira, que impediam que modelasse a estrutura de meu projeto da forma que eu gostaria.
|
|
|
|
andersonlfl wrote:Nos clusters que ja disponibilizei as aplicações que trabalhei, nunca fiz transferencia de objetos "conscientemente", ou seja, se existe alguma comunicacao trafegando objetos isso fica a cargo do servidor de aplicação. O DTO nesse caso seria usado pelo servidor de aplicação ?
Em um parque de clusters, você tem várias JVMs... espalhadas entre as máquinas, ok? Quando você trabalha com objetos distribuídos, como EJBs, a única referência que você tem são as interfaces, você não sabe em qual máquina pode estar a implementação.
Por tanto, você pode ter seu framework web trabalhando em uma máquina, e o EJB estar em outra. O responsável por realizar o algoritmo para replicação dos estados no parque, gerenciar o contexto JNDI, a atualização, o escalonamento e outras atividades de infraestrutura é o APPServer com seu conteiner EJb. Se a sua aplicação utiliza EntityBean 2.x e seu ambiente é conforme eu descrevi, quem deve criar DTOs para evitar possíveis chamadas remotas desnecessárias é o desenvolvedor... o conteiner EJB faz o papel dele apenas distribuindo e gerenciando os objetos.
Se você não utiliza EJB, mas sua aplicação esta em cluster, então não existe este problema. As chamadas vão ser sempre locais. Quando sua aplicação muda de host, leva consigo todas as suas classes e objetos, portanto ao reivindicar um objeto, este estara na própria JVM do objeto solicitante, logo não a necessidade de criar objetos para trafegar em camadas físicas já que estão na mesma.
|
|
|
|
andersonlfl wrote:Via webservices comum seria muito diferente justificando o uso do DTO ?
Entendo que como WebService "comum", você esteja se referindo a utilização de SOAP e end-points ao estilo JAX-RPC (não que isso seja de fato o "comum", mas talvez um formato bastante difundido ... é isso mesmo?). De qualquer maneira, creio que sua pergunta é: utilizar ou não DTOs em WebService... a resposta é "não".
Não faz sentido, uma vez que o WebService expõem end-points de serviço e não métodos de acessibilidade a atributos de objetos de domínio (você não tem métodos getters e setters expostos em um webService ). Um Webservice pode ser comparado a um Session Bean (obviamente muito mais heterogêneo), e não a um Entity Bean.
Lembre-se que os DTOs são meios de economizar chamadas remotas a antigos EntityBeans e não a Sessions, para estes ultimos usamos Session Façade.
Quando você passa um objeto como parâmetro em uma chamada de um webservice (o que normalmente se atribui o nome de "tipos complexos"), tal objeto pode ser um POJO qualquer, inclusive uma entidade JPA com métodos de negócio.
|
|
|
|
|
http://java.sun.com/blueprints/corej2eepatterns/Patterns/TransferObject.html
|
|
|
|
O EJB pode oferecer interfaces remotas para qualquer aplicativo local Java que vc desejar.
Um exemplo do seu uso é na concetração de lógicas de negócio em processos remotos e compartilhar tais processos em aplicativos ou front-ends diferentes (como com os webservices, que tbm são modelos distribuídos de programação). Não estou afirmando que esse modelo de programação seja bom ou ruim, Fowler por exemplo faz sérias objeções quanto a isso (ou pelo menos de como isso era implementado em Java nas suas versões anteriores).
Uma outra usabilidade é rodar os processos em clusters, ou em núcleos diferentes de CPUs.
Bom, se você utilizar o modelo J2EE de desenvolvimento distribuído (Session e EntityBeans) sem utilizar padrões como SessionFaçade ou TO (DTO), você terá sérios probelmas de performance.
Na antiga especificação EJB 2.x, um EntityBean possui interface remota para todos seus métodos gets e sets. Imagine que para cada utilização de simples objeto.getNome(), ou usuario.setSenha('xxx'), sejam realizadas chamadas remotas, isso é um absurdo. Para isso se criavam objetos fakes (os DTOs) não distribuíveis (não EJBs) e serializáveis, com vários atributos de um ou vários EntityBeans. Estes objetos deveriam ser manipulados por um client local da forma que se queira e enviados uma única vez para um objeto distribuído (quase sempre um EJB SessionFaçade). Então remotamente, este objeto era desmembrado (padrão Assembler) em verdadeiros objetos de domínio EntityBean, que então são manipulados na persistência.
Hoje em dia, não existe mais por que fazer isso. Os EntityBeans se transformaram em Entities JPA, locais e serializáveis. Ele mesmo navega entre as camadas locais e remotas.
Como você vê, utilizar DTOs sem que esteja em uma aplicação distribuída e com a antiga especificação, não faz sentido.
|
|
|
|
|
Fabio... leia os posts que se seguiram ...
|
|
|
|
|
Amém.
|
|
|
|
Depende da aplicação e cada caso é um caso.
Se sua entidade de negócio precisar de algo na camada de persistência, vc pode colocar como atributo de sua entidade um repositorio de dados e delegar consultas a este repositório de dentro de sua entidade (só não deve, ou melhor, geralmente não se recomenda, acessar diretamente a API de persitência (JDBC, JPA, ou qualquer coisa do gênero) de dentro de uma entidade).
Seu repositório de dados pode ser a interface de um DAO especialista daquele domínio ou uma classe especialista que contenha um DAO genérico como atributo.
OBS: Se bem que isso não é regra... um repositório de dados pode ser qualquer coisa que armazene dados, desde que seus métodos sejam voltados ao negócio, e não para infra de acesso a dados. Dado a isso dizemos também que um repositório faz parte do negócio e não da persistência.
|
|
|
|
Bom, no seu caso, seria algo do tipo.
Se você utilizar DAO (a classe abaixo é o básico do básico):
Vc não precisa ter um DAO para cada Tabela, mas preferencialmente para cada Entidade "forte" de seu negócio.
Pode tbm tentar o uso de DAOs Genéricos (dê uma busca rapida neste forum sobre isso).
Mas sinceramente, não reinvente a roda, use um framework[2].
|
|
|
|
java_coffe wrote: Nâo estou utilizando DTO ........So quiz dizer que eu ja modelei meu diagrama de classe agora quero criar a persistencia da minha aplicação .
Quero saber como eu modelo da melhor forma a parte de persistencia da minha aplicação !? Eu crio as classes de acordo com as tabelas do banco 
Mas pq fazer isso se vc já criou suas classes de negócio? É elas que você tem que utilizar, e não réplicas do seu banco de dados.
Quando vc realizar alguma consulta no banco, retorne seus objetos de negócio.
|
|
|
|
Desculpe, não entendi sua dúvida.
Você disse :
Gente eu modelei meu diagrama de classe onde as classes estao todas modeladas de uma forma mais organizada possivél !!!!
... e depois disse:
No caso eu tenho que criar as minhas classes de acordo com modelo relacional do banco de dados(...)?
Você já não tinha criado suas classes (de maneira mais organizada possível)? O que é maneira organizada? Porque criar DTOs (é uma aplicação distribuída usando EJB 2.x)?
|
|
|
|