| Autor |
Mensagem |
|
|
Então... é a formalização de soluções recorrentes...
O conceito é antigo e não nasceu na computação, mas ganhou muita relevância no mundo orientado à objetos.
A bibliografia sobre o assunto á é bem ampla:
Design Patterns: Elements of Reusable Object-Oriented Software - Gang of Four
Using Pattern Languages for Object-Oriented Programs - Kent Beck, Ward Cunningham
Patterns of Enterprise Application Architecture - Martin Fowler ...
Existem vários blogs que publicam implementações diversas de padrões de projeto, eu mesmo comecei a fazer isso no meu, e pretendo colocar mais alguns.
Abraço
|
 |
|
|
Ai jisuis... Tem tempo que eu não faço isso, e não tenho nenhum código de exemplo aqui... Mas...
O Tomcat vem com um servlet mapeado como "default" . Então vc só precisa adicionar tags assim:
<servlet-mapping>
<servlet-name>default</servlet-name>
<url-pattern>/urlEspecíficaQueVcNaoQuerQuePassePeloOutroServlet</url-pattern>
</servlet-mapping>
Acho que isso resolve o problema...
|
|
|
|
Cara, mapeia esse casos em que vc quer fazer bypass para o servlet default.
Abrex.
|
|
|
|
SEBASTIÃO, eis a minha opinião:
Nossas classes são a "receita" para se construir objetos de um determinado tipo. Objetos que materializam a mesma classe tem o mesmo conjunto de propriedades e métodos. As classes definem propriedades e métodos justamente porque nossos objetos deveriam refletir "indivíduos" do mundo real e consequentemente possuir estado e comportamento.
Agora um exercício de abstração:
Com aquela arquitetura-padrão-j2ee-n-layer pretendia-se antender a uma necessidade de sistemas distribuidos... Compartilhar o estado dos objetos entre máquinas diferentes.
Forçando bastante esse exercício de abstração, pode-se dizer que a união de várias classes-java em camadas diferentes formava uma classe-de-negócio. Por exemplo (simplificado): o conceito Cliente podia ser reproduzido pelo conjunto ClienteBO-ClienteDTO. Eu particularmente nunca gostei disso, mas nem considero uma heresia muito grande, desde que você tenha isso bem claro em mente durante a modelagem.
Essa forma de desenhar sistemas foi absurdamente vulgarizada. É como se houvesse uma solução de caixinha assim: ColoqueONomeDoCasoDeUsoAquiDAO, ColoqueONomeDoCasoDeUsoAquiBO, ColoqueONomeDoCasoDeUsoAquiFacade... Onde você só precisava substituir ColoqueONomeDoCasoDeUsoAqui por Cliente, ou Usuário, ou Projeto, ou qualquer substantivo nascido dos seus requisitos. Desde que você fizesse uma classe de cada camada para cada substantivo, você seria um cara de vanguarda, desenvolvendo soluções OO, portáveis, J2EE, absurdamente escaláveis. Seria convidado para dar palestrar em Nova York e Oslo, e por aí vai.
O grande mérito do DDD, na minha opinião, foi provocar uma "guinada filosófica", do tipo: "Eu fui contratado para usar J2EE, ou para resolver um problema da melhor forma que eu conseguir?". Modificou-se o paradigma. Ao invés de se pensar em como resolver o problema que você ainda nem conhece, agora entende-se e modela-se todo o ambiente que envolve o problema antes de se preocupar com questões meramente computacionais.
Quando vocês se desvinvula daquele "Padrão J2EE" você percebe que existem alternativas simples e naturais para resolver as questões computacionais. Por exemplo... As pessoas simplesmente existem no mundo, o mundo não serializa elas em um banco de dados enquanto elas dormem (pelo menos eu acho que não, fiquei bolado agora...). A necessidade de se persistir de alguma forma as pessoas não é natural, mas é bem clara em um modelo computacional. Definiu-se o padrão Repositório, que ajuda a abstrair esse pequeno entrave, fazendo com que lidar com pessoas seja o mais natural possível. A pessoa simplesmente está lá, não interessa ao cerne do problema como elas estão, desde que estejam.
Acho que você não deve, mas até pode usar a modelagem "Padrão J2EE", desde que seja um ninja da capacidade de abstração.
Se você for um cara normal que nem eu, compre o livro de DDD Evans, o de padrões do Fowler... Estude para caramba. Se você for mesmo normal como eu, a cada vez que você olhar o código, vai identificar uma coisinha que deveria fazer diferente... Por isso você deveria comprar logo o livro de Refactory do Fowler. A partir de um determinando momento o desenvolvimento será natural.
Não acho que seja fundamental seguir o Evans. Acho que o importantíssimo é entender que somos desenvolvedores de software, entendemos de computador e temos que nos esforçar para entender ao máximo o ambiente no qual o nosso produto está inserido. Feito isso devemos nos dar ao direito de refletir, discutir, inventar... que é a parte mais legal do nosso trabalho. Não se preocupe com o que é certo ou errado, tente conhecer todos os pontos de vista, e alinhe-se àquilo que te parece mais simples e natural (no meu caso o que pareceu ser mais simples e natural está descrito no livro do Evans).
Seria correto eu elimiar essa camada de negocio..que pra mim invalida todo conceito de O.O e colocar minhas regras de negocio junto com meus atributos numa mesma classes? ou seja, eu teria a classe...
Com certeza seria correto, mas várias outras coisas seriam corretas... Estude todas elas para embasar sua opinião, desde que depois você junte estado e comportamento dos elementos do seu domínio naa suas classes de domínio. Use repositórios e não deixe vazar absolutamente nadinha da sua infra de persistência para a camada de domínio, nada significa nada mesmo (nem querys, nem exceptions, nem nada). Agregue suas classes de domínio, e respeite essas agregações, por mais que doa às vezes, há uma razão de ser... e use sempre protetor solar!
Abraço
|
|
|
|
Eu discordo dessa visão... Acho que explicitar a dúvida fomenta a discussão e acaba refinando a informação e aumentando o conhecimento de todo mundo.
Pedir orientação nunca é ruim...
|
|
|
|
Cara, faz um rs.next ao invés de um rs.first.
Abraço
|
|
|
|
Opa, escrevi sobre isso no meu blog ontem... http://www.sectioaurea.com.br/diogopontual !!!
Vc falou que o seu DAO trata das transações, normalmente acho que isso deve ficar um pouco mais acima.
Abraço
|
|
|
|
Caramba, tivemos esse problema aqui na empresa. JPA é muito maneiro, mas a equipe tem que entender direitinho o Lazy Load, e como fazer os relacionamentos. Havia um many-to-many, com as coleções nas duas pontas, e tentava-se serializar uma delas para mandar para um cliente Flex, e tomávamos um StackOverflow na testa... Linda oortunidade para se usar (direito) DTO.
Por uma série de motivos, e por causa dos riscos envolvidos, eu preferi, em um novo projeto, abandonar JPA e utilizar as facilidades que o Spring oferece para a camada de dados, usando JDBC mesmo. Pelo menos está me parecendo mais elegante!!!
|
|
|
|
Opa, Bom dia,
Acho que antes de pensar em ser DDD, devemos pensar em ser OO.
Cada classe deve ter estado e comportamento de um determinado conceito. A camada de domínio deve encerrar tudo àquilo que disser respeito ao domínio do negócio... Essas coisas todas!!!
Você não precisa corrigir seu sistema todo de uma vez, mas precisa identificar o que deve ser mudado, planejar e ir fazendo. Acho que vale a pena (Sempre) ler o Refactoring do Fowler.
Sempre, sempre, sempre procure por Patterns para resolver os probleminhas que aparecem, mas não precisa se amarrar a eles!!! Muito cuidado com os patterns daquele catálogo de J2EE, alguns deles nem deveriam ser tão patterns assim, e melecam nosso sistema.
Dê atencão especial à comunicação, tanto a falada e escrita pela equipe em documentação, quanto pela expressada no código. Seja minucioso para escolher nomes, e faça com que os nomes sejam comuns às conversas, aos documentos e ao código.
Enfim, é assim que estou tentando ser DDD aqui, e está dando razoavelmente certo.
|
|
|
|
Acho que o pessoal está confundindo Alhos com Bugalhos...
Alguns conceitos para embasar meus argumentos:
DTO => É uma "classe/estrutura de dados", serve para: Estruturar dados... Um Map também é uma estrutura de dados... Ambos podem ser usados nas mesmas situações (e devem ser usados apenas em situações bem especĩficas).
XML => eXtensible Markup Language... No contexto da thread serve apenas como formato no qual os dados transitarão na rede... Não compete nem com os mapas, nem com os DTO's... Ambos podem ser serializados em XML, para transitar na rede. (Normalmente eu uso JSON pq é bem menos verboso).
Fujam de DTO, a não ser quando eles forem usados na fronteira entre duas camadas heterogêneas, em termos de máquinas, ou tecnologia ou coisas assim... Ou seja: Só use DTO's quando precisar estabelecer uma barreira bem clara para os seus objetos de negócio (a causa dessa fronteira pode ser um requisito de segurança, máquinas diferentes, tecnologias diferentes...). Não os use para tráfegar dados dentro da fronteira da sua própria aplicação...
|
|
|
|
|
Tenho usado o Astah Community mesmo, e está tudo certo...
|
|
|
|
JPA já te oferece prontas várias facilidades, como lazy load, caches e por aí vai, que vão, no melhor dos mundos, "otimizar" o acesso aos dados...
Apesar disso, o que tenho visto é o pessoal usando recursos como lazy load sem estudá-lo, e consequentemente fazendo besteira.
|
|
|
|
Cara,
Da forma como é utilizada corriqueiramente, JPA é JDBC Puro. Com uma camadinha de "tradução" no meio... Mas no final das contas, é JDBC.
Quanto às questões de performance, eu afirmo peremptoriamente que ninguém nesse mundo está habilitado à responder à sua pergunta enquanto ela estiver despida de um contexto. Se o nosso contexto for um simples: "select * from algumaCoisa", JPA é menos performático do que JDBC Puro, visto que ela "extende" JDBC, inserindo umas complicaçõeszinhas... Por outro lado, se o seu contexto incluir diversos "select * from algumaCoisa", e o objeto resultante da consulta agregar alguns outros objetos... Ai, se bem usado, JPA vai se tornar mais performático...
Também não é uma verdade universal que o desenvolvimento sobre JPA é mais produtivo que sobre JDBC... Talvez alguns desenvolvedores dominem muito bem JPA e se tornem bastante produtivos. (Mas para ser honesto o que eu tenho visto por aí é muito erro... Aninhamentos de agregações que não terminam nunca, problemas com transações, etc, etc, etc).
O meu conselho normalmente é: Tente isolar completamente a camada de persistência através do uso de alguns padrões de projeto. (Repository, QueryObject...), escolha a tecnologia que vc e sua equipe se sentem mais à vontade, e toque o pau... Se no futuro vc resolver mudar de idéia, não vai dar muito trabalho.
Enfim, o importante é um design do projeto que estabeleça bem claramente as responsbilidades... E aí (apesar de não ser ponto pacífico), acho que as práticas do DDD podem te ajudar bastante (e os principais livros de patterns).
Abraço
|
|
|
|
Oi kweles.
Normalmente esse não é o melhor caminho. Provavelmente a sua Exception passa por uma série de camadas antes de chegar ao cliente Flex. Nessas camadas podem acontecer outras Exceptions por outros motivos, e você não vai poder identificá-las para dar o tratamento adequado. Acho que você deve criar uma Exception específica para a situação que a gerou.
Esse texto é interessante sobre o uso de Exceptions:
http://today.java.net/article/2006/04/04/exception-handling-antipatterns
Abraço.
|
|
|
|
Essas máscaras de ip estão certas para o seu ip??? Em caso positivo dê uma olhar na em listen_addresses no arquivo postgresql.conf. Se e num me engano o padrão é localhost. bota um * .
Abraço.
|
|
|
|
|
|