Leonardo3001 wrote:Tem uma coisa que eu não entendi: como posso substituir TO por interfaces quando a apresentação e o negócio estão em TIERS diferentes? Até onde eu sei, o cliente recebe um objeto em formato serializável, e pra deserializá-lo, é necessário a definição da classe no lado cliente também.

Supondo que, com interface não dá, existe jeito de se separar a aplicação em TIERS, sem usar TO, mas ao mesmo tempo, concentrar a regra de negócio no lado servidor?

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."

Paulo Silveira wrote:

sergiotaborda wrote:

emerleite wrote:

sergiotaborda wrote:
1) Suas entidades são ricas , tão ricas que contêm métodos que alteram o estado do sistema como um todo.
Um chamada no momento errado a esses métodos e "Bum!". Neste caso não é bom passar suas entidades para lado nenhum. Crie outros objetos com o mesmo estado e sem métodos ( aka TO) ( trabalheira)

TO, DTO São para evitar chamadas remotas e não para evitar o problema em questão.

Isso é o que eles querem que vc acredite.
O ponto em questão é levar os dados (do dominio) até à camada de apresentação. Isso é inerentemente um problema de transporte. Logo é a própria definição de um objeto de transfrencia de dados, de transporte (TO)

Um caso particular do uso disse é quando fazemos chamadas remotas, mas isso é apenas um caso particular de um padrão mais genérico.

Particular? A Sun, O Fowler e todos os lugares que voce encontrar a descricao, voce vai ver que fala que é para evitar o acumulo de chamadas remotas de granularidade fina:
http://java.sun.com/blueprints/patterns/TransferObject.html
http://www.martinfowler.com/eaaCatalog/dataTransferObject.html

Em que caso usariamos esse padrao mais generico, e onde ha a descricao? nao consigo ver a utilidade de usar DTo/TO sem ser para transferir dados entre TIERS (e nao layers).

emerleite wrote:

sergiotaborda wrote:
O ponto em questão é levar os dados (do dominio) até à camada de apresentação. Isso é inerentemente um problema de transporte. Logo é a própria definição de um objeto de transfrencia de dados, de transporte (TO)

Um caso particular do uso disse é quando fazemos chamadas remotas, mas isso é apenas um caso particular de um padrão mais genérico.

Sergio, a sua referência é ao seu próprio Blog. Leiamos as fontes originais que citei acima. É possível que você tenha lido o livro Core J2EE Patterns em português, que a tradução é horrível, como 99% dos casos.

Na tradução, está escrito camadas, sem fazer diferença entre Layer e Tier.

Sinceramente ainda não entendi esse argumento de programar perigosamente. Poderia exemplificar em código pra ficar mais claro?

rob1980a wrote:Tenho acompanhado as discussoes sobre "domains" e para levar um dominio ate a camada de apresentação. Voces acham que é interessante levar um objeto de dominio ate a camada de apresentacao, pq alguem pode chamar um metodo de negocio dele?

Num JSF voces mapeam o Managed Bean com os mesmos campos do domain?

Vlw!

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)

sergiotaborda wrote:
Por isso que as entidades de dominio não podem ter métodos que altera o seu estado ( aka ActiveRecord)

Das duas uma:
1) Suas entidades são ricas , tão ricas que contêm métodos que alteram o estado do sistema como um todo.
Um chamada no momento errado a esses métodos e "Bum!". Neste caso não é bom passar suas entidades para lado nenhum. Crie outros objetos com o mesmo estado e sem métodos ( aka TO) ( trabalheira)
2) Suas entidades são pobre ou ricas, mas não tão ricas que contenham métodos que explodem seu sistema.
Neste caso um chamada aos método altera no máximo a propria entidade e suas filhas. mas como não ha um método "save" essas alterações não causam efeito no estado do sistema como um todo. Aqui não precisa de TO, pode usar os objetos de entidade normalmente.

É uma violação do isolamento do dominio ? Pode até ser que seja, mas é um trade-off. É melhor isso que criar TO iguazinhos às entidades só para que eles viajem nas camadas.

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)

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.