问一个关于Linq多层结构的问题！

Question

在传统的三层中，我们可以利用比如工厂模式在数据层实现多数据库扩展支持但是如果采用Linq，比如Linq To SQL,那么Linq实体将贯穿表面层，业务逻辑层，数据层如果我想进行数据库移植的话，Linq实体必然是要随之改变的我在MSDN杂志上曾经看到过一篇，在表面层和业务层中加一个服务层来实现实体层的隔离，但是看的也不太明白目前是否有比较好的解决方案？希望高人指点！

Answer 1

Linq中并没有实体这种东西，它是Linq to SQL中的，所以结论很明白，你说Linq贯穿业务逻辑层没有问题，说Linq to SQL贯穿业务逻辑层就有问题了，这就意味只你的业务逻辑成就只能用于Linq to SQL所支持的数据库。

Answer 2

数据库 (LINQ to SQL) 
DataSet 数据集(LINQ to Dataset) 
XML文档 (LINQ to XML)  
实体对象 (LINK to Entities) 
http://www.cnblogs.com/entlibforum/articles/1236715.html

Answer 3

对，是Linq To SQL 实体，Linq是不会出现在逻辑层和表现层的是Linq2Sql实体贯穿三层，比如业务逻辑层有这样的方法
Function GetAllList as List(Of User_Table)
那么User_Table就是一个Linq2Sql实体，我就必须在业务逻辑层引用实体类同样在表面层也必须要引用了可以在逻辑上实现不引用吗

Answer 4

事实上，最近对分层耿耿于怀，感觉还是没有透彻今天是看了这篇文章产生这个疑问的http://msdn.microsoft.com/zh-cn/magazine/cc700340.aspx你能不能帮我看下，不是非常明白~

Answer 5

Linq to SQL是Linq，但反之并不成立。如果你本末倒置，自然会被时髦的名词反而害了设计，因为你号称是在基于Linq设计业务逻辑层，而实际上不离Linq to SQL。linq只有查询功能，并没有数据库更改功能，也就是说数据库更改你应该定义或者使用一个通用的接口。

Answer 6

在帖子《谈谈ORM触发器设计》中我在77楼贴了一个数据库通用接口，可以参考。

Answer 7

我习惯直接说Linq了，其实就是Linq To Sql，Linq基本是不会出现在业务层的，可能根本都没有我想问的是，是否有好的方案可以避免Linq To SQL实体类在多层中都出现我的想法是，我既然在要实现多数据库支持，那么实体的出现必然是不合理的当然，这个纯粹是研究多层结构。这个不是为了应用~

Answer 8

如果你没有办法实现类似这样很通用的在业务逻辑层里针对“任意对象”的操作接口，那么你就不得不将这个接口隐藏在DAL层里，而业务逻辑层就无法实现为针对“任意对象”的而只能是为每一种业务领域对象都建立一套查询、更改方法接口。

Answer 9

唉，在基本逻辑上总是满拧的，如果你使用Linq to SQL来实现业务逻辑，就是在使用Linq来实现。而反之并不成立。如果你缺乏逻辑训练，又怎么来深入学习技术呢？！

Answer 10

你讲的这个我看懂了，但是还不是太透彻，我待会儿再研究一下然后你看了我给你的那个链接没
http://msdn.microsoft.com/zh-cn/magazine/cc700340.aspx 这个貌似也有点意思，但是我不能很看明白，你能给我介绍一下这个文章想要表达和实现的是什么吗我感觉和我的想法很接近~

Answer 11

在业务里是没有LINQ的，我的想法应该是在数据里实现Linq to SQL,这样应该是合理的吧