LINQ to SQL N-Tier com serviços Web
O LINQ to SQL foi projetado especialmente para uso na camada intermediária em uma camada de acesso a dados (DAL) de acoplamento flexível, como um serviço Web. Se a camada de apresentação for uma página da Web ASP.NET, use o LinqDataSource controle de servidor Web para gerenciar a transferência de dados entre a interface do usuário e o LINQ to SQL na camada intermediária. Se a camada de apresentação não for uma página ASP.NET, tanto a camada intermediária quanto a camada de apresentação deverão fazer algum trabalho adicional para gerenciar a serialização e a desserialização de dados.
Configurando o LINQ to SQL na camada intermediária
Em um serviço Web ou aplicativo de n camadas, a camada intermediária contém o contexto de dados e as classes de entidade. Você pode criar essas classes manualmente ou usando o SQLMetal.exe ou o Object Relational Designer, conforme descrito em outro lugar na documentação. Em tempo de design, você tem a opção de tornar as classes de entidade serializáveis. Para obter mais informações, consulte Como tornar entidades serializáveis. Outra opção é criar um conjunto separado de classes que encapsulam os dados a serem serializados e, em seguida, projetam nesses tipos serializáveis quando você retorna dados em suas consultas LINQ.
Em seguida, você define a interface com os métodos que os clientes chamarão para recuperar, inserir e atualizar dados. Os métodos de interface envolvem suas consultas LINQ. Você pode usar qualquer tipo de mecanismo de serialização para lidar com as chamadas de método remoto e a serialização de dados. O único requisito é que, se você tiver relações cíclicas ou bidirecionais em seu modelo de objeto, como entre Clientes e Pedidos no modelo de objeto Northwind padrão, deverá usar um serializador que ofereça suporte a ele. O Windows Communication Foundation (WCF) DataContractSerializer oferece suporte a relações bidirecionais, mas o XmlSerializer que é usado com serviços Web não-WCF não. Se você optar por usar o XmlSerializer, então você deve certificar-se de que seu modelo de objeto não tem relações cíclicas.
Para obter mais informações sobre o Windows Communication Foundation, consulte Windows Communication Foundation Services e WCF Data Services no Visual Studio.
Implemente suas regras de negócios ou outra lógica específica de domínio usando as classes parciais e os DataContext métodos nas classes de entidade e para se conectar a eventos de tempo de execução do LINQ to SQL. Para obter mais informações, consulte Implementando a lógica de negócios de n camadas.
Definindo os tipos serializáveis
O cliente ou a camada de apresentação deve ter definições de tipo para as classes que receberá da camada intermediária. Esses tipos podem ser as próprias classes de entidade ou classes especiais que envolvem apenas determinados campos das classes de entidade para comunicação remota. Em qualquer caso, o LINQ to SQL não está completamente preocupado com a forma como a camada de apresentação adquire essas definições de tipo. Por exemplo, a camada de apresentação pode usar o WCF para gerar os tipos automaticamente, ou pode ter uma cópia de uma DLL na qual esses tipos são definidos, ou pode apenas definir suas próprias versões dos 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 do DataContext, executa uma consulta em uma ou mais de sua tabela. A camada intermediária retorna o resultado como um IEnumerable<T>, onde T é uma classe de entidade ou outro tipo usado para serialização. A camada de apresentação nunca envia ou recebe variáveis de consulta diretamente da camada intermediária. As duas camadas trocam valores, objetos e coleções de dados concretos. Depois de receber uma coleção, a camada de apresentação pode usar LINQ to Objects para consultá-la, se necessário.
Ao inserir dados, a camada de apresentação pode construir um novo objeto e enviá-lo para a camada intermediária, ou pode fazer com que a camada intermediária construa o objeto com base nos valores que ele fornece. Em geral, recuperar e inserir dados em aplicativos de n camadas não difere muito do processo em aplicativos de 2 camadas. Para obter mais informações, consulte Consultando o banco de dados e Fazendo e enviando alterações de dados.
Controlar alterações para atualizações e exclusões
O LINQ to SQL oferece suporte à simultaneidade otimista com base em carimbos de data/hora (também chamados RowVersions) e em valores originais. Se as tabelas de banco de dados tiverem carimbos de data/hora, as atualizações e exclusões exigirão pouco trabalho extra na camada intermediária ou na camada de apresentação. No entanto, se você precisar usar valores originais para verificações de simultaneidade otimistas, a camada de apresentação será responsável por rastrear esses valores e enviá-los de volta quando fizer atualizações. Isso ocorre porque as alterações feitas nas entidades na camada de apresentação não são rastreadas na camada intermediária. Na verdade, a recuperação original de uma entidade e a eventual atualização feita nela são normalmente realizadas por duas instâncias completamente separadas do DataContext.
Quanto maior o número de alterações feitas pela camada de apresentação, mais complexo se torna controlar essas alterações e empacotá-las de volta para a camada intermediária. A implementação de um mecanismo de comunicação de alterações depende inteiramente da aplicação. O único requisito é que o LINQ to SQL deve receber os valores originais necessários para verificações de simultaneidade otimistas.
Para obter mais informações, consulte Recuperação de dados e operações CUD em aplicativos de N camadas (LINQ to SQL).