Melhores Práticas: 3-Tier Architecture in LINQ

Question

Eu estou trabalhando em um projeto pessoal (C # / ASP.NET) que irá usar o LINQ to SQL. A solução terá (até agora) um projeto Webform, um projeto Namespace (lógica de negócio), e um testes do projeto. Eu estou nos estágios iniciais até agora (claramente em Design de fase).

Existe um paradigma para 3-Tier Architecture aqui? Parece que a DAL é totalmente inútil neste caso; Parece que eu deveria estar realizando a consulta LINQ diretamente da lógica de negócios.

Também ocorre-me que se eu apenas manter um morador DataContext e passar essa aí, eu só precisa de um conexão aberta. Isso teria a vantagem de cometer alterações de uma só vez, em vez de granular. Quaisquer pensamentos sobre isso?

esta discussão , mas parece pintar um quadro incompleto. Existem quaisquer artigos em profundidade sobre o assunto?

Answer 1

Você pode pensar em LINQ to SQL como seu DAL, de modo a usá-lo "diretamente da lógica de negócios" não é necessariamente uma coisa ruim.

http://dotnetlog.com/archive/2008/03/18/best-practice-and-effective-way-of-using-datacontext-in-linq.aspx tem algumas L2S populares abordagens da lista .

Em nosso projeto, nós não quer passar em todo o contexto de dados por isso usamos um padrão semelhante ao nº 3 a partir do link acima (Ambient DataContext, veja abaixo). Ele teve alguns problemas, mas funcionou razoavelmente bem; pelo menos para o nosso projeto web.

Ambient DataContext (atualmente usando este)

A idéia por trás datacontext ambiente é que o contexto é criado para um segmento específico ou um HttpContext (em asp.net), logo que há uma primeira chamada para o DataContext. Em seguida, o mesmo contexto é utilizado para esse segmento ou pedido, a menos que ele está disposto manualmente. Isso é feito por armazenar o contexto no armazenamento de dados pedido / thread. A abordagem a este padrão é semelhante à estática DataContext, no entanto, a separação é fornecido para cada thread e solicitações. Isso funciona muito bem em Asp.Net, no entanto, é mais uma vez atormentado por alguns dos problemas de contexto estático.

Os problemas com este padrão:

* The context is available for manipulation at any level. And quickly becomes very hard to maintain unit of work
* Portability across thread is very hard
* Unit of work pattern is not transparent enough

Answer 2

Você pode ler um pouco sobre Domain Driven projeto.

Com a prática de Domain Driven Design (DDD), você tem uma rica 'modelo de domínio', em que você expressa o domínio do problema que pretende resolver. Este modelo de domínio consiste em aulas (e estruturas) com o qual você modelar seu entidades empresariais. O modelo de domínio também consits de repositórios.
Um repositório é uma espécie de abstração que você usa no seu modelo de domínio (e em sua aplicação); O repositório é uma abstração de seu armazenamento de dados. Através do repositório, você pode recuperar entidades, e você pode usar o repositório de persistir entidades.

No seu caso, seus repositórios poderia usar o LINQ to SQL internamente para falar com o banco de dados. Nota no entanto, que seu repositório não deve ser responsável para gerenciar (/ perto aberto) a conexão ea operação (start / commit / rollback) embora. Por quê ? -> porque o Repositório não tem conhecimento ou noção do contexto em que ela é usada. É de sua aplicação ou camada de serviço (a camada que usa seu modelo de domínio e, portanto, seu repositório) que deve ser responsável por abrir uma nova conexão e iniciar / cometer transações. (Ou no seu caso, abra um novo DataContext). Você poderia, então, passar o DataContext para o repositório.

(Eric Evans tem um grande livro sobre DDD, embora um osso duro de roer, de vez em quando).

Answer 3

Você deve ter cuidado com a sua terminologia. Quando você diz LINQ você quer dizer Linq-to-sql e quando você diz 3-tier que normalmente significa que você está falando de um cenário de implantação com 3 máquinas separadas. Eu não tenho certeza se é isso que você quer dizer.

A arquitetura de três camadas ainda é uma boa ideia quando se usa uma ferramenta ORM como sql linq-to-. A DAL torna-se apenas um lugar para armazenar sua lógica de consulta. É uma boa idéia para tirar suas dúvidas fora de sua camada de negócios porque as consultas são uma preocupação a persistência, não uma preocupação lógica de negócios.

A técnica usual para gerir o contexto de dados é ter um único contexto de dados por solicitação.

Em termos de outros artigos sobre o assunto você pode olhar para qualquer orientação arquitetura para qualquer ferramenta ORM - LINQ to SQL não é diferente. Procure artigos sobre arquitetura para NHibernate.

Answer 4

O LINQ to SQL biblioteca é a sua DAL neste caso, e em vez de fazer chamadas de API tradicionais de sua camada de negócios (por exemplo DAL.GetObjectById (id)) você tem a flexibilidade de solicitações muito mais expressivos na DAL.

Se você teve algumas outras necessidades, como por exemplo o seu próprio provedor de LINQ que se conecta a um MSSQL não-apoio de dados, então você poderia implementar seu próprio DAL.

Além disso sobre o DataContext, não é recomendado o uso de um padrão singleton com "um DataContext residente". Um DataContext objeto deve representar uma única transação lógica, o que isso significa para a sua aplicação. (Parafraseado de http://weblogs.asp.net/despos/archive/2008/03/19/more-on-datacontext-in-hopefully-a-realistic-world.aspx )