Observação
O acesso a essa página exige autorização. Você pode tentar entrar ou alterar diretórios.
O acesso a essa página exige autorização. Você pode tentar alterar os diretórios.
O LINQ to SQL foi projetado especialmente para uso na camada intermediária em uma DAL (camada de acesso a dados) flexívelmente acoplada, como um serviço Web. Se a camada de apresentação for uma página da Web ASP.NET, você usará o controle do LinqDataSource servidor Web para gerenciar a transferência de dados entre a interface do usuário e o LINQ para o SQL na camada intermediária. Se a camada de apresentação não for uma página ASP.NET, a camada intermediária e a camada de apresentação deverão realizar algum trabalho adicional para gerenciar a serialização e desserialização dos dados.
Configurando o LINQ para 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 SQLMetal.exe ou o Designer Relacional de Objetos, 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 as entidades serializáveis. Outra opção é criar um conjunto separado de classes que encapsulam os dados a serem serializados e, em seguida, projetar esses tipos serializáveis quando você retornar 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 encapsulam 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 a entre Clientes e Pedidos no modelo de objeto Northwind padrão, deverá usar um serializador compatível com ele. 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ê selecionar usar o XmlSerializer, deverá verificar se o modelo de objeto não tem relações cíclicas.
Para obter mais informações sobre o Windows Communication Foundation, consulte o Windows Communication Foundation Services e o 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 obter mais informações, consulte Implementando a lógica de negócios de N camadas.
Definindo os tipos serializáveis
A camada de cliente ou apresentação deve ter definições de tipo para as classes que receberá da camada intermediária. Esses tipos podem ser a entidade classificam-se, ou classes especiais que envolvem apenas determinados campos de entidade classe remoting. De qualquer forma, o LINQ to SQL não está completamente preocupado sobre 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 suas tabelas. Em seguida, a camada intermediária retorna o resultado como um IEnumerable<T>, onde T é uma classe de entidade ou outro tipo utilizado para serialização. A camada de apresentação nunca envia ou recebe variáveis de consulta diretamente para ou 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 poderá 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 fazer com que a camada intermediária construa o objeto com base nos valores fornecidos por ele. 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 Consultar o banco de dados e fazer e enviar alterações de dados.
Acompanhamento de alterações para atualizações e exclusões
O LINQ to SQL dá suporte à simultaneidade otimista com base em marcas de data e hora (também chamadas de 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 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 acompanhar esses valores e enviá-los de volta quando fizer atualizações. Isso ocorre porque as alterações feitas em entidades na camada de apresentação não são controladas na camada intermediária. Na verdade, a recuperação original de uma entidade e a atualização eventual feita a ela normalmente são executadas por duas instâncias completamente separadas do DataContext.
Quanto maior o número de alterações feitas pela camada de apresentação, mais complexa ela se torna para controlar essas alterações e empacotá-las de volta para a camada intermediária. A implementação de um mecanismo para comunicar alterações depende inteiramente do aplicativo. O único requisito é que LINQ to SQL deve receber os valores originais necessários para verificações de simultaneidade otimistas.
Para mais informações, consulte Recuperação de Dados e Operações CUD em Aplicações N-Tier (LINQ to SQL).