Domain na Camada de Apresentação (Preciosismo?)

Forum Spammer Membro desde: 22/03/2005 20:57:48 Mensagens: 3201 Offline

cmoscoso wrote:
Será que precisamos de um padrão pra isso?

Eu apenas uso o sufixo Helper ou Result.

Essa sua pergunta tem tantas implicações que não me atrevo a descrevê-las todas. O essencial é:
1) Prefixos e Sufixos não fazem padrões.
2) Um objeto segue padrões mesmo quando vc não sabe que eles os segue ou não o desenhou pensando em algum padrão. Por vezes é institivo.

É como fazer 2+2=4 alheio ao fato disse ser possivel porque o conjunto dos inteiros é um grupo para a adição. Ignorar que é , não impede de usar.

Virtual Machine Man Membro desde: 23/10/2007 10:08:29 Mensagens: 684 Offline

sergiotaborda wrote:
Essa perguntinha é muito boa porque demonstra que TO tem muitas mais aplicações.

E qual a vantagem de estar sob as rédeas de um padrão que impõe várias restrições sendo que não vou utiliza-lo no contexto para qual ele foi criado?

sergiotaborda wrote:
hummm... é possivel também que eu tenha citado essas mesmas fontes entre outras e tirado minhas própria conclusões. Essas eram as conclusões em que me baseie para responder e por isso citei o meu blog. Afinal um padrão que serve para "poupar invocações remotas" parece no minimo tosco. Tem que haver uma razão mais primitiva para que algo seja considerado um padrão. Mas como já tive que me explicar no outro posto , peço que o leia.

Design Patterns, em sua maioria, costumam ser remendos que a linguagem ou a tecnologia nao conseguem suprir... É assim mesmo...

Virtual Machine Man Membro desde: 23/10/2007 10:08:29 Mensagens: 684 Offline

sergiotaborda wrote:
Essa sua pergunta tem tantas implicações que não me atrevo a descrevê-las todas. O essencial é:
1) Prefixos e Sufixos não fazem padrões.

cmoscoso wrote:
Será que precisamos de um padrão pra isso?
Será que precisamos de um padrão pra isso?
Será que precisamos de um padrão pra isso?

sergiotaborda wrote:
2) Um objeto segue padrões mesmo quando vc não sabe que eles os segue ou não o desenhou pensando em algum padrão. Por vezes é institivo.

Foi assim, por "instinto", que concluiu isso?

... LocalDTO is when you have a significant mismatch between the model in your presentation layer and the underlying domain model.

So pra deixar claro. Nao é pra criar Local DTO e copiar e colar todos seus atributos. E sim quando voce quer decorar, diminuir, expor algo de maneira diferente para o outro layer.

cmoscoso wrote:
Foi assim, por "instinto", que concluiu isso?

É, o Sergio entendeu voce ao contrario denovo ai.

Virtual Machine Man Membro desde: 21/01/2004 14:12:54 Mensagens: 618 Offline

Não precisamos usar padrão se assim preferirmos para nada Carlos. Contudo é uma forma para referirmos aos mesmos problemas e suas respectivas soluções.

O exemplo que citei é uma situação dessas. Como mencionado pelo Sérgio, você pode transferir uma SQL diretamente ou uma entidade de domínio, optar por um novo objeto customizado é uma solução diferente para a mesma motivação, que sabemos ser bem mais razoável do que os outros approachs.

Forum Spammer Membro desde: 22/03/2005 20:57:48 Mensagens: 3201 Offline

Paulo Silveira wrote:

sergiotaborda wrote:
hummm... é possivel também que eu tenha citado essas mesmas fontes entre outras e tirado minhas própria conclusões. Essas eram as conclusões em que me baseie para responder e por isso citei o meu blog. Afinal um padrão que serve para "poupar invocações remotas" parece no minimo tosco. Tem que haver uma razão mais primitiva para que algo seja considerado um padrão. Mas como já tive que me explicar no outro posto , peço que o leia.

Design Patterns, em sua maioria, costumam ser remendos que a linguagem ou a tecnologia nao conseguem suprir... É assim mesmo...

Mais uma vez não tenho palavras para explicar como isso é um tremendo erro. Design Patterns são, sim, na sua maioria corolários do uso do Principio da Separação de Responsabilidade e/ou do Principio da Inversão do Controle. Não são rememdos. São mecanismos formais diretamente relacionados aos principios de OO.

Se colocar um numero de pessoas desenhando sistema OO durante um bom tempo, depois de algum tempo eles vão chegar na conclusão que estão criando sempre o mesmo tipo de objetos. O seguimento das regras de OO leva naturalmente a isso. Como essas implementações especiais , esses trade-off especiais se repetem , ele são catalogados. E isso é um pattern : um conjunto de aplicações de principios o OO que para um determinado problema sempre resultam na mesma solução. Então, sabendo o problema e a solução catalogada vc poupo o tempo e a pericia de utilizar os principios OO do zero. Afinal , não é todo o mundo que sabe fazer isso.

É mais ou menos como na fisica. Vc tem formulas. Mas elas são derivadas de principios primários. As formulas são apenas ajudas catalogadas para não derivar tudo do principio cada vez que é necessário.

Contudo, vc é livre de começar dos principios cada vez e chegar no objeto final. Muitas vezes isso é feito naturalmente - por instinto - se que vc se aperceba que aquilo é um padrão já catalogado. Aliás, para vc reconhecer isso vc tem que conhecer o padrão primeiro.

Me assusta que vc jogue no lixo todo um conjunto de teorias e principios que estão pode detrás de OO e reduza tudo a "remendos"...

sergiotaborda wrote:

Mais uma vez não tenho palavras para explicar como isso é um tremendo erro. Design Patterns são, sim, na sua maioria corolários do uso do Principio da Separação de Responsabilidade e/ou do Principio da Inversão do Controle. Não são rememdos. São mecanismos formais diretamente relacionados aos principios de OO.

Se colocar um numero de pessoas desenhando sistema OO durante um bom tempo, depois de algum tempo eles vão chegar na conclusão que estão criando sempre o mesmo tipo de objetos. O seguimento das regras de OO leva naturalmente a isso. Como essas implementações especiais , esses trade-off especiais se repetem , ele são catalogados. E isso é um pattern : um conjunto de aplicações de principios o OO que para um determinado problema sempre resultam na mesma solução. Então, sabendo o problema e a solução catalogada vc poupo o tempo e a pericia de utilizar os principios OO do zero. Afinal , não é todo o mundo que sabe fazer isso.

É mais ou menos como na fisica. Vc tem formulas. Mas elas são derivadas de principios primários. As formulas são apenas ajudas catalogadas para não derivar tudo do principio cada vez que é necessário.

Contudo, vc é livre de começar dos principios cada vez e chegar no objeto final. Muitas vezes isso é feito naturalmente - por instinto - se que vc se aperceba que aquilo é um padrão já catalogado. Aliás, para vc reconhecer isso vc tem que conhecer o padrão primeiro.

Me assusta que vc jogue no lixo todo um conjunto de teorias e principios que estão pode detrás de OO e reduza tudo a "remendos"...

ah, isso me lembra velhas discussões

T+

sergiotaborda wrote:
O pessoa do EJB começou a usar TO porque eles definiam chamadas assim :
metodo ( String a, String b, int c);
E rápidamente entenderam que seria melhor assim
class X { String a; String b; int c; } class Bean { metodo (X x ); }

Mais uma vez isso nada tem a ver com o padrão TO/DTO. O que você citou é um Refactoring Pattern chamado Introduce Parameter Object, que nada tem a ver com TO/DTO.
http://www.refactoring.com/catalog/introduceParameterObject.html

sergiotaborda wrote:
O fato de X ser Serializable era uma obrigação do modelo do EJB que era remoto por default. O padrão TO não precisava disso. Era o EJB quem precisava. Afinal o EJB corre junto do Web container , porque chamadas remotas ? Porque o EJB não definia chamadas locais.
Quando começou a fazê-lo na nova versão do EJB com o LocalInterface o uso de TO não parou. Porquê?
Se o TO fosse para poupar invocações remotas, ele não seria mais necessário, já que elas não existiam mais.

Mas o objetivo do TO nunca foi esse. Sempre foi diminuir a granularidade. Por isso que mesmo com o advento do LocalInterface o TO continuou sendo usado.

Tanto isso não é verdade que na prova de Certificação em EJB geralmente caia uma pergunta sobre o uso dos Transfer Objects e a única resposta correta era para diminuição de chamadas remotas. O fato do TO não ter morrido na documentação da Sun se da mais pelo fato da falta de atualização correta, tanto que tem algumas paginas deles que ainda chamam esses objetos de VOs.

sergiotaborda wrote:
Pense mais dois minutos: Num sistema web com EJB quantos tiers vc normalmente tem ? UM! (os casos em que vc tem mais que um são raros)
E então porque vc usava objetos remotos ? Porque o EJB obrigava (nas primeira versões)
Quando o LocalInterface chegou porque vc não parou de usar TO ? Afinal continuavamos tendo apenas UM tier e agora sem invocação remota: a razão de usar TO para diminuir invocações remotas não existia mais.
Então porque se continuou usando TO ? Porque continuou importante a necessidade de usar objeto coarse-grain.

Entendam que essa era a falha fatal do EJB pré-3 : todos os objetos eram serializáveis e invocados remotamente mesmo quando só existia um TIER. Aliás, mesmo quando só existia uma JVM.
Mesmo com o advento das interfaces locais que eximiam o EJB de fazer chamadas remotas as pessoas continuaram usando TO. Então estavam usando TO para passar objetos apenas entre camadas , já que a JVM era a mesma. O Tier era o mesmo !

Não precisa de literatura para entender este fato historico se vc alguma vez trabalhou com EJB e TO.
SEMPRE só houve um tier! Isos é ainda mais evidente com o uso de LocalInterface. Não me venham com essa conversa que objetos passados entre camadas não são TO que isso é completamente absurdo. O objetivo do padrão é alterar a granularidade. Apenas isso.

Hoje o Seams faz sucesso por implementar o obvio. Aquilo que o EJB deveria ter sido do inicio. Mas o EJB nasceu do Corba que é remoto por natureza. Esse foi o erro. Isso foi o que fez nascer coisas como o DDD e o Spring e o proprio EJB 3.

A única ocasião onde faz sentido falar em mais do que um tier era quando a interface não era web ( swing por exemplo) onde vc realmente tinha vários tiers. Ou quando vc comunicava com algum legado via CORBA.
Mas isso sempre foi raro. Rápidamente se percebeu que usar Web era muito mais vatajoso exactamente porque tudo estava no mesmo tier. A tecnologia não evoluio para o EJB 3 com interfaces locais porque a maioria dos sistema tem clientes remotos ou acessa legados remotos.

Não está correto seus argumentos. Quando você diz que sempre houve um só TIER, você ignora o fato do EJB 1.x não ter interfaces locais e por isso a criação dos padrões Session Façade e Transfer Object.

sergiotaborda wrote:
hummm... é possivel também que eu tenha citado essas mesmas fontes entre outras e tirado minhas própria conclusões. Essas eram as conclusões em que me baseie para responder e por isso citei o meu blog. Afinal um padrão que serve para "poupar invocações remotas" parece no minimo tosco. Tem que haver uma razão mais primitiva para que algo seja considerado um padrão. Mas como já tive que me explicar no outro posto , peço que o leia.

Esse padrão para poupar invocações remotas surgiu de uma limitação dos Entity Beans e era a maneira recorrente de resolver o problema. Por isso um padrão.

This message was edited 2 times. Last update was at 30/04/2008 13:35:04

cmoscoso wrote:

Lezinho wrote:Como vocês classificam os objetos fakes como aqueles necessários em relatórios ad-hoc, que são apenas uma customização de dados do domínio? (claro, dentro da mesma tier)

Como não pertencentes ao domínio.

Lezinho wrote:
Talvez tenha me expressado mal Moscoso, que ele não é domínio já esta implícito na sua condição de customização do domínio, não era a isso que me referia.

Se ele não é um VO (esse nome hoje tem uma referencia mais forte a sua definição em DDD), não é um TO/DTO (isso é, se você toma como convenção que essa padrão se aplica somente em invocações remotas)... então do que podemos chamar esses objetos que muitas vezes são necessários? Não me recordo do registro de algum padrão específico (se convencionarmos que DTO = remoteCall ) que dá nome para essa situação necessária em muitos casos.

sergiotaborda wrote:Essa perguntinha é muito boa porque demonstra que TO tem muitas mais aplicações.

De acordo com o PEAA Pag. 350, esses objetos são Helpers (e.g. UsuarioHelper), atendendo ao padrão Template View.
http://martinfowler.com/eaaCatalog/templateView.html

ISSO NÃO É TO/DTO. REPITA COMIGO: NÃO É TO/DTO. MAIS UMA VEZ: NÃO É TO/DTO.

Valeu pelos posts pessoal,

Li o link http://www.martinfowler.com/bliki/LocalDTO.html e pelo que entendi ele fala que não seria um trabalho extra duplicar a informacao de dominio para a apresentacao(no caso MB) nos casos de diferencas entre aprensentacao e dominio, esta realmente correto isso?

Como vcs mapeariam um MB caso a solução fosse retornar o objeto de dominio para a apresentacao? Numa tela de cadastro de cliente, como ficaria mapeado o MB? Com os mesmos campos do Domain? Usariam o dominio como mapeamento?

Vlw!

This message was edited 1 time. Last update was at 30/04/2008 16:47:04

emerleite wrote:

sergiotaborda wrote:
O fato de X ser Serializable era uma obrigação do modelo do EJB que era remoto por default. O padrão TO não precisava disso. Era o EJB quem precisava. Afinal o EJB corre junto do Web container , porque chamadas remotas ? Porque o EJB não definia chamadas locais.
Quando começou a fazê-lo na nova versão do EJB com o LocalInterface o uso de TO não parou. Porquê?
Se o TO fosse para poupar invocações remotas, ele não seria mais necessário, já que elas não existiam mais.

Mas o objetivo do TO nunca foi esse. Sempre foi diminuir a granularidade. Por isso que mesmo com o advento do LocalInterface o TO continuou sendo usado.

Tanto isso não é verdade que na prova de Certificação em EJB geralmente caia uma pergunta sobre o uso dos Transfer Objects e a única resposta correta era para diminuição de chamadas remotas.

De tudo o que vc disse eu vou só comentar esta parte porque o resto é incomentável.
Isto que vc disse é o exemplo do que eu me referia com "é isso que eles querem que vc acredite".
Me diga, quais eram as outras opções ? Alguma delas era "para diminuir a granularidade da invocação" ?

Se vc quiser continuar acreditando nisso. Otimo. Quer continuar vivendo na ideade das trevas da tecnologia distribuida. Otimo.Mas que ninguem diga que eu não tentei levá-los à luz.

This message was edited 1 time. Last update was at 30/04/2008 20:57:56

pcalcado wrote:Se estamos falando de como a Camada de Apresentação de uma aplicação se comunica com a Camada de Negócios dela realmente qualquer coisa que

Não simplesmente passar os objetos é estranho. No caso de uma API se proteger com interfaces e factories é mais do que suficiente, creio.

E esse artigo é ótimo: http://martinfowler.com/bliki/LocalDTO.html:

Martin Fowler's Bliki wrote:
DTOs are called Data Transfer Objects because their whole purpose is to shift data in expensive remote calls. They are part of implementing a coarse grained interface which a remote interface needs for performance. Not just do you not need them in a local context, they are actually harmful both because a coarse-grained API is more difficult to use and because you have to do all the work moving data from your domain or data source layer into the DTOs.
Some people argue for them as part of a Service Layer API because they ensure that service layer clients aren't dependent upon an underlying Domain Model. While that may be handy, I don't think it's worth the cost of all of that data mapping. As my contributor Randy Stafford says in P of EAA "Don't underestimate the cost of [using DTOs].... It's significant, and it's painful - perhaps second only to the cost and pain of object-relational mapping".
Another argument I've heard is using them in case you want to distribute later. This kind of speculative distribution boundary is what I rail against with the FirstLaw. Adding remote boundaries adds complexity. So I'd echo Randy's advice "start with a locally invocable Service Layer whose method signatures deal in domain objects. Add remotability when you need it (if ever) by putting Remote Facades on your Service Layer or having your Service Layer objects implement remote interfaces."

No contexto de CBD, algumas pessoas julgam necessária uma abordagem parecida como a citada por Fowler. Utilizando algo como um DTO ou PO para garantir que o cliente fique desacoplado de uma implementação (por exemplo, da implementação de um subsistema, POJOS com regras de negocio), considerando os DTOs e POs como parte da interface (API).

Assim poderíamos, por exemplo, alterar o domínio utilizando um padrão do GOF - visando flexibilidade - sem alterar a interface do subsistema. (substituir uma herança por uma estratégia state do GoF, PF e PJ herdando de Pessoa para Pessoa agrega uma interface comum de PF e PJ).

Essa abordagem parece razoável, mas tem um custo que não compensa (citado por Fowler). Principalmente em consultas, não existe muitas complicações em objetos de domínio "vazar..." Mas e na criação de um objeto?

Instanciar um objeto gera acoplamento (GRASP), no caso estaríamos instanciando um objeto de domínio fora da cama de negócio... Eu sei que a camada de apresentação não necessita desse "cuidado", mas essa falta de "coesão" pode gerar outros problemas. Um objeto de domínio representa as regras de negocio, essas regras podem gerar exceções de negócio. Podemos ter regras em construtores e em métodos set..., disparando exceções de negócio (alterações de estados podem gerar validações).

Essas questões são tratadas na camada de negócio, mas no caso de um cadastro? O objeto deve ser instanciado na camada de apresentação? Criando para isso construtores e métodos set... sem regras e outros métodos com as regras para serem utilizados apenas na camada de negócio? Neste caso não é melhor usar um PO, deixando os objetos de domínios só com métodos de negocio?

This message was edited 1 time. Last update was at 30/04/2008 23:04:56

Gustavo Serafim wrote:Um objeto de domínio representa as regras de negocio, essas regras podem gerar exceções de negócio. Podemos ter regras em construtores e em métodos set..., disparando exceções de negócio (alterações de estados podem gerar validações). Essas questões são tratadas na camada de negócio(...)

Qual o problema de vazar para a camada de aplicação uma exceção de negócio? Se você recebe uma exceção do domínio na camada app, prepare uma mensagem ao cliente UI relatando o problema... enquanto se isso acontece na camada de domínio, outros objetos poderiam tomar outras decisões ainda referente ao negócio (ou tbm propagar para app layer). De qualquer maneira, a camada de aplicação não codifica nada no domínio e nem implementou suas regras, portanto não vejo problemas.

Gustavo Serafim wrote:(...)Criando para isso construtores e métodos set... sem regras e outros métodos com as regras para serem utilizados apenas na camada de negócio? Neste caso não é melhor usar um PO, deixando os objetos de domínios só com métodos de negocio?

Os PersistenceObjects de hoje em dia são classes convencionais tão quanto o modelo do domínio, pra que separar os dois? Replicar todos os objetos de domínio apenas pq algum programador pode fazer alguma besteira na camada de aplicação pode ser um trabalho imenso sem garantia de que o mesmo programador vai seguir a regra de usar o PO clean no lugar do DomainObject.

Notícias, artigos e o maior fórum brasileiro sobre Java