LINQ to SQL de n camadas com serviços da Web
O LINQ to SQL é projetado principalmente para uso na camada intermediária em uma camada fracamente acoplada (DAL) de acesso a dados como um serviço Web. Se a camada de apresentação é uma página da Web ASP.NET, então você usa o controle de servidor Web de LinqDataSource para gerenciar a transferência de dados entre a interface do usuário e LINQ to SQL na camada intermediária. Se a camada de apresentação não é uma página ASP.NET, então a camada intermediária e a camada de apresentação devem fazer qualquer trabalho adicional para gerenciar serialização e desserialização de dados.
Foundation LINQ to SQL na camada intermediária
Em um serviço Web ou em um aplicativo de n camadas, a camada intermediária contém o contexto de dados e classes de entidade. Você pode criar essas classes manualmente, ou usando SQLMetal.exe ou o Object Relational Designer como descrito em outro lugar na documentação. Em tempo de design, você tem a opção fazer as classes de entidade serializável. Para mais informações, confira Como tornar as entidades serializáveis. Outra opção é criar um conjunto separado de classes que encapsulam os dados a ser serializados, e em projetos nesses tipos serializados quando você retorna dados nas consultas do LINQ.
Você então define a interface com métodos que os clientes chamarão para recuperar, inserir e atualizar dados. Os métodos de interface envolvem as consultas do LINQ. Você pode usar qualquer tipo de mecanismo de serialização para manipular chamadas remotos do método e serialização de dados. O único requisito é que se você tiver relações cíclicas ou bidirecionais no seu modelo de objeto, tal como aquela entre clientes e pedidos no modelo de objeto padrão do Northwind, então você deve usar um serializador que ofereça. O WCF (Windows Communication Foundation) DataContractSerializer dá suporte a relações bidirecionais, mas o XmlSerializer usado com serviços Web não WCF, não. Se você escolher usar o XmlSerializer, o modelo de objeto não deverá ter relação cíclica.
Para mais informações sobre o Windows Communication Foundation, confira Serviços do Windows Communication Foundation e WCF Data Services no Visual Studio.
Implemente suas regras comerciais ou outra lógica específica de domínio usando as classes e métodos parciais em DataContext e classes de entidade para ligar em eventos no runtime do LINQ to SQL. Para mais informações, confira Como implementar a lógica de negócios de N camadas.
Definindo tipos Serializable
O cliente ou a camada de apresentação devem ter definições de tipo para as classes que será recebendo de camada intermediária. Esses tipos podem ser a entidade classificam-se, ou classes especiais que envolvem apenas determinados campos de entidade classe remoting. Em qualquer caso, o LINQ to SQL é completamente indiferente sobre como a camada de apresentação obtém essas definições de tipo. Por exemplo, a camada de apresentação pode usar WCF para gerar automaticamente os tipos, ou pode ter uma cópia de uma DLL em que esses tipos são definidos, ou pode apenas definir suas próprias versões de tipos.
Recuperando e inserindo dados
A camada intermediária define uma interface que especifica como a camada de apresentação acessa os dados. Por exemplo, GetProductByID(int productID) ou GetCustomers(). Na camada intermediária, o corpo do método normalmente cria uma nova instância de DataContext, executa uma consulta em uma ou mais da tabela. A camada intermediária então retorna o resultado como IEnumerable<T>, onde T é uma classe de entidade ou outro tipo que é usado para serialização. A camada de apresentação nunca envia ou recebe variáveis de consulta diretamente ou da camada intermediária. Os dois valores de troca de camadas, objetos, e coleções de dados concretos. Depois que recebeu uma coleção, a camada de apresentação pode usar o LINQ to Objects para consultá-la, se necessário.
Para inserir dados, a camada de apresentação pode criar um novo objeto e enviá-lo para a camada intermediária, ou pode fazer com que a camada intermediária criar o objeto com base nos valores que fornece. Em geral, recuperar e inserir dados em aplicativos n-tier não difere do processo muito 2 em aplicativos de camada. Para mais informações, confira Como consultar o banco de dados e Como fazer e enviar alterações de dados.
Controlar alterações para atualizações e exclusões
O LINQ to SQL dá suporte para simultaneidade otimista com base nos carimbos de data/hora (também chamados RowVersions) e valores originais. Se as tabelas de base de dados têm carimbos de data/hora, então atualizações e exclusões exigem vez trabalho adicional na camada intermediária na camada de apresentação. Entretanto, se você deve usar valores originais para verificação de simultaneidade otimista, então a camada de apresentação é responsável para controlar os valores e enviá-los novamente quando fazer atualizações. Isso ocorre porque as alterações que foram feitas às entidades na camada de apresentação não são controladas na camada intermediária. De fato, a recuperação original de uma entidade, e a atualização feita a eventual ele normalmente são executadas por duas instâncias separadas de DataContextcompletamente.
Maior o número de alterações que a camada de apresentação isso, ele fica mais complexa para controlar as alterações e para empacotar-las de volta para a camada intermediária. A implementação de um mecanismo para alterações de comunicação é completamente até o aplicativo. O único requisito é que o LINQ to SQL deve receber os valores originais necessários para verificação de simultaneidade otimista.
Para mais informações, confira Recuperação de dados e operações de CUD em aplicativos de N Camadas (LINQ to SQL).