Emerson Macedo wrote:

sergiotaborda wrote:
E não ha essa diferença tão destinta entre tier e layer. Aliás, se ler o JEE Core Patterns vai entender que eles usam os dois termos meio que indestintamente.
A destinção não é tão rigida como faz pensar.

Acho que você deve ter lido o livro em português, onde a tradução como de costume péssima, chama tudo de camada, não fazendo distinção entre Layer e Tier.

sergiotaborda wrote:
Você achas demasiadas coisas de mim ...
Eu só leio livros tecnicos dessa importância em ingles.

Core J2EE Patterns wrote:
Transfer Object


Problem
You want to transfer multiple data elements over a tier.

Forces

You want clients to access components in other tiers to retrieve and update data.

You want to reduce remote requests across the network.

You want to avoid network performance degradation coused by chattier applications that have high network traffic.

Solution
Use a Transfer Object to carry multiple data elements across a tier.

Emerson Macedo wrote:
Então me desculpe, pois já que você leu em inglês, deve ter lido esse trecho do livro sobre o Pattern TO:

Core J2EE Patterns wrote:
Transfer Object

(...)
Problem
You want to transfer multiple data elements over a tier.

Paulo Silveira wrote:
De qualquer maneira, mesmo que voce concorde com isso, acho que ai o nome nao deveria chamar DTO, ja que esse padrao eh pra tier.

Emerson Macedo wrote:
Então me desculpe, pois já que você leu em inglês, deve ter lido esse trecho do livro sobre o Pattern TO:

http://java.sun.com/blueprints/corej2eepatterns/Patterns/DataAccessObject.html wrote:
TransferObject

This represents a Transfer Object used as a data carrier. The DataAccessObject may use a Transfer Object to return data to the client. The DataAccessObject may also receive the data from the client in a Transfer Object to update the data in the data source.

sergiotaborda wrote:
E não ha essa diferença tão destinta entre tier e layer. Aliás, se ler o JEE Core Patterns vai entender que eles usam os dois termos meio que indestintamente.
A destinção não é tão rigida como faz pensar.

Emerson Macedo wrote:

Core J2EE Patterns wrote:
Use a Transfer Object to carry multiple data elements across a tier.

Core J2EE Patterns wrote:

Transfer Object
The Composite Entity creates a composite Transfer Object and returns it to the client. the Trasnfer Object is used oto carry data from de Composite Entity and its dependent objects.

Emerson Macedo wrote:

sergiotaborda wrote:
E não ha essa diferença tão destinta entre tier e layer. Aliás, se ler o JEE Core Patterns vai entender que eles usam os dois termos meio que indestintamente.
A destinção não é tão rigida como faz pensar.

Acho que você deve ter lido o livro em português, onde a tradução como de costume péssima, chama tudo de camada, não fazendo distinção entre Layer e Tier.

sergiotaborda wrote:
Ha uma variante que é um pouco mais diferente ( not really) que implica em comprimir a serialização. Isso sim é um DTO real. O nome DTO adveio dese padrão de compressão. Mas como num objeto so com atributos não ha o que comprimir o JEE COre Patterns passou a ideia de que o DTO era apenas um conjunto de atributos serializáveis e pronto. Não é apenas isso. O DTO original continha mecanismo de compressão (por exemplo, listas que nsó serializam os objetos realmente diferentes).

Lezinho wrote:public class HibernateDao implements Dao{ //injetado via DI Session session; public void save(Object obj){ session.save(obj); } public void update(Object obj){ session.update(obj); } public void delete(Object obj){ session.delete(obj); } public List find(String query){ return session.createQuery(query).list(); } }

Lezinho wrote:Como mencionei Tarso, é um draft e não uma implementação que descrevi. Com certeza teria para o "find" uma lista de parâmetros no código de produção além de outras coisas.

Mas essa lista de parâmetros (ou como tbm mencionei, um QueryObject com diferentes traduções e argumentos), não tem nada específico de qualquer API... logo não é dependência.

rodrigoy wrote:Eu já nem entro mais nessas discussões.... não adianta... quando será que vocês vão compreender que DDD não é sobre padrões? O nível de cerimônia e de débito técnico pode variar entre as aplicações. Não dá pra pegar a literatura e aplicar "as-is" como uma cartilha.

rodrigoy wrote:
Vou falar uma coisa aqui que posso até ser crucificado por vocês: uma aplicação com domínio anêmico na implementação pode ser desenvolvida usando DDD. Depende do domínio.

rodrigoy wrote:
Um Active Record do Ruby é manifestado declarando claramente dependência de infra:

class PedidoVenda < ActiveRecord::Base ... end

Creio que na opinião de vocês não dá pra desenvolver nada em DDD no Rails. Só no mundinho hermético onde temos Entities, Hibernate, DAOs, Camadas é que podemos ter DDD, certo?

rodrigoy wrote:
Vamos imaginar que eu consiga manifestar um conceito de domínio na "YoshiLanguage" da seguinte maneira:
[...]
Vocês poderiam dizer que nessa listagem não estamos usando DDD por que os padrões não estão claros como na literatura ou porque tenho dependências de conceitos da minha implementação?

tnaires wrote:
Entendo, mas não deixa de ser uma gambiarra, porque eu não usaria essa lista de parâmetros se não fosse com JDBC ( ia ter que passar um valor null ).