passando dados numa aplicação ntier

Question

Como você passar dados para camadas em um aplicativo n-tier? I mapeou 3 métodos diferentes.

A) .net genérico objetos tabelas de dados genéricos, Hashtables, conjuntos de dados genéricos, cordas, ints etc ... em seguida, usando os conjuntos de dados para preencher os seus objetos de negócios que são enviados para a camada de interface do usuário.

alt texto http://img11.imageshack.us/img11/460/generic. png

http://dabbleboard.com/draw?b=eiu165&i=26&c=54eef6f1ac01f03c85919518f4a24e798e57e133

Pro - Não há camadas extras necessários Con - tem que trabalhar com conjuntos de dados genéricos e tabelas na camada de negócios

B) usando uma camada de entidades que as outras camadas faria referência. Esta camada deve conter conjuntos de dados, quer rigidez ou Plain Old C Objects. Os objetos seriam principalmente dados de contêineres e muito pouco de lógica. estes seriam os mesmos objetos enviados para a camada de interface do usuário.

alt texto http://img8.imageshack.us/img8/6454/entities. png

http://dabbleboard.com/draw?b=eiu165&i=6&c=d0c2b346894a96b12bd3867f630e474a2af098fa

Pro - trabalhando com as mesmas classes em todas as camadas Con - adicionando uma referência para entities.dll a todas as camadas

C) uso de objectos de transferência de dados (conatiner objetos apenas) definidos na camada DataAccess. em seguida, usando esses objetos para preencher objetos de negócios que são enviados para a camada de interface do usuário.

alt texto http://img43.imageshack.us/img43/1236/transferp. png

http://dabbleboard.com/draw?b=eiu165&i=27&c=f886efa3f9d5eb4b45ddb02361c79cdcdaec0a9b

Pro - a camada de negócios não teria que trabalhar com classes genéricas Con - trabalhar com dois tipos de objetos e você teria para hidratar os objetos de negócios com os objetos de transferência

Tivemos uma discussão no trabalho e queria ver o que pensava a comunidade. Eu também adicionei um link para o Dabbleboard. copie e criar em vez de editar.
Graças

Answer 1

Se você estiver usando um em camadas abordagem, ou seja, todas as camadas são (essencialmente) em execução no mesmo espaço de processo e não há, portanto, nenhuma triagem / serialização, eu iria com abordagem B. Criar um módulo separado para as suas entidades sobre as quais todos os aspectos de seu programa dependem, e par a isso.

Se, no entanto, você está usando um tiered abordagem como seu título sugere, o que significa que são limites de processo e / ou de rede que são cruzadas, eu sugiro que você vá com a abordagem C. Você 'não está realmente passando instâncias ao redor, você está passando cópias, portanto, quaisquer benefícios que você começa a acoplar ao mesmo objeto, como opções observáveis ??para, digamos, uma abordagem MVC, são perdidos de qualquer maneira. Melhor para definir APIs de dados em todos os níveis nível do que tentar usar a mesma classe de todos os lados.

Answer 2

Grande pergunta -. Como sempre, a resposta tem que ser "depende"

Por tipo de aplicação, e se existe realmente uma necessidade de ter objetos de negócios (entidades), em oposição a objetos de transferência (isto é dumbed-down negócio objetos que correspondem mais a entidades de banco de dados).

Tradicionalmente, eu teria argumentado que você sempre tem a necessidade de conjuntos de dados genéricos (ou tabelas de dados), puramente por razões de desempenho. Sempre que há uma necessidade de trabalhar com, exibir ou manipular conjuntos maiores, a maneira OO estrita tradicional de instanciar um grande número de objetos de negócios falhou.

No entanto, desde que eu comecei a trabalhar com LINQ to SQL, meus paradigmas mudaram. Não há mais a necessidade de esta em tudo, desde o modelo de Linq pode ser tudo - objetos de negócios, objetos de transferência, e conjuntos de dados genéricos. Eu ainda não explorado como isso funciona bem em realmente grandes aplicações, e se deve haver uma necessidade de código front-end isolado a partir do modelo de Linq. Eu tive discussões sobre isso com os colegas, sem realmente encontrar uma resposta de qualquer maneira.

Answer 3

Eu como opção C, mas também me dá uma pausa por dois motivos:

1. Eu tenho que espalhar a knwowledge do que os properites estão em muitos lugares.
2. DTO tem que ser serializável, o que não é terrível, mas ainda uma consideração.

Answer 4

Estou assumindo todas as 3 camadas existe dentro do mesmo aplicativo. Em java pelo menos eu usei Hibernate para acesso de dados e usou esses beans de dados em todas as camadas. (Opção B) Faz sentido de ser capaz de reutilizar as entidades em suas camadas.