问一个关于三层中包含LINQ的问题

r_y_y_d 2009-01-08 04:27:15

以前没有LINQ时，三层还是比较清晰的

现在有了Linq，好像不太清晰了

在业务层会采用Linq语法操作Linq类，

而有时候表面层也可能用到应用到Linq实体类

在用LINQ的情况下，是否有较清晰的解决方案。

不是为了三层而三层。或者说这样就可以了？

...全文

516 21 打赏收藏转发到动态举报

写回复

用AI写文章

21 条回复

切换为时间正序

请发表友善的回复…

发表回复

wjy217213 2011-07-25

打赏
举报

学习了

校长大人 2010-09-28

打赏
举报

我觉得你这个问题有两种解决方案
1，把LINQ中的实体类COPY 出来，重新放一命名空间当中。这样就可以在页面层和，数据层共享实体类，而不发生冲突。不过这样又点繁琐，消弱了方便的意义。
2 ，使用wcf，这样的话，可以端只需要和 wcf 进行交互，层次就分明了！

jansulucas 2009-10-14

打赏
举报

学习鸟。。多谢各位的无私奉献

以专业开发人员为伍 2009-01-08

打赏
举报

能不能长久、放心地把Linq作为BLL工具，这就要看Linq是不是有能力能让更多的数据库产品开发公司所支持。当你自己写一套东西，我在8楼说过了，要注意那个问题。

r_y_y_d 2009-01-08

打赏
举报

[Quote=引用 16 楼 sp1234 的回复:]
当你站在Linq框架的角度，也就是比Linq to SQL的原型接口的角度 --> 当你站在Linq框架的角度，也就是Linq to SQL的高一层“原型”的角度
[/Quote]

是不是就是说如果我的项目就是基于Linq To SQL，不会出现数据库移植等扩展，那么我就直接在业务层用DataContext进行操作

如果我的项目如果存在扩展，以后还有可能抛弃Linq，或者用其他数据库，那么就需要在外面再包一层，给业务层提供接口

以专业开发人员为伍 2009-01-08

打赏
举报

当你站在Linq框架的角度，也就是比Linq to SQL的原型接口的角度 --> 当你站在Linq框架的角度，也就是Linq to SQL的高一层“原型”的角度

以专业开发人员为伍 2009-01-08

打赏
举报

当你使用Linq to SQL的时候，从Linq框架角度去使用各种Linq实现都支持的东西。例如我就觉得DataContext可有可无的（你可以使用ADO.NET直接修改SqlServer数据库中的数据而不一定一定通过DataContext）。或者，写一个关于将对象更新到数据库的通用接口（也不过4、5个简单方法而已），并实现这个接口（底层虽然还是使用DataContext实现，但是是隐藏了它），这样就为各种Linq实现的切换做好准备。当你站在Linq框架的角度，也就是比Linq to SQL的原型接口的角度，就会更好去使用Linq的通用的那些作用而避免具体Linq实现的“方言”特性。

如果你写代码时几乎不用其考虑Linq to SQL方言，即使将数据库切换为Linq to MYSQL、Linq to Excel、Linq to XML 甚至 Linq to GoogleSearch 也很容易，此时你的Linq代码其实就是BLL同等概念了。

善缘2022 2009-01-08

打赏
举报

是的，功能可以实现就行。不必强求三层。

beijingqinghuadaxue 2009-01-08

打赏
举报

Linq的重点其实也很简单，就是面向对象的查询语言，不论是关系数据库、面向对象数据库，甚至内存数据数组，其查询遍历的语法都是基本上一样的SQL类似的语法，这样Linq也可以用来快速地进行算法分析和实现（而不需要你去写伪代码来说明程序的计算算法了）。

顶

不必强求三层

还顶

mengxj85 2009-01-08

打赏
举报

学习，同意楼上，不必强求三层

yangshenghong 2009-01-08

打赏
举报

不必强求3层

gongsun 2009-01-08

打赏
举报

埋头学习中...

r_y_y_d 2009-01-08

打赏
举报

[Quote=引用 7 楼 sp1234 的回复:]
我不太清楚你说的Linq到底是指Linq还是特指Linq to SQL。如果是指Linq框架本身，那么你要看看你的代码是否可以具有兼容各种Linq实现的倾向性。

不管是否兼容性都很高，但是Linq框架本身确实是一种Provider框架，也就是让我们摆脱各种DAL的差异的束缚。从这个意义上，Linq就是一种通用的BLL工具库。你的自定义BLL类再调用Linq来补充其功能，甚至“表面层”直接调用Linq，都是更加强调了与DAL的解耦这个设计特点。
[/Quote]

在这里我指的就是Linq To Sql，我的意思是，现在有了Linq语法后，我是否还需要再去特别构造一个数据层（ORM之上的一层)

因为我觉得我在业务层里直接使用Linq语法操作数据库不就可以了吗

以专业开发人员为伍 2009-01-08

打赏
举报

实际上，如果你开发过ORM就会发现，搞一个面向对象风格的数据存取api很容易，可是你想搞一个让（上述我给出的Google结果中你可以看看Linq Provider的不下20种类实现，并且许多都并不是关系数据库）这些各种各样的DAL都能兼容的类似SQL风格的统一的查询语言，以一般人的能力几乎是10辈子也不可能实现的。由于没有真正面向对象的查询功能，所以许多自己开发的ORM都是似是而非的ORM，它可能让用户输入一个string来代表查询规则，这怎么能将实现机制完全不同的DAL一网打尽呢？所以，Linq的重点其实也很简单，就是面向对象的查询语言，不论是关系数据库、面向对象数据库，甚至内存数据数组，其查询遍历的语法都是基本上一样的SQL类似的语法，这样Linq也可以用来快速地进行算法分析和实现（而不需要你去写伪代码来说明程序的计算算法了）。

以专业开发人员为伍 2009-01-08

打赏
举报

我不太清楚你说的Linq到底是指Linq还是特指Linq to SQL。如果是指Linq框架本身，那么你要看看你的代码是否可以具有兼容各种Linq实现的倾向性。

不管是否兼容性都很高，但是Linq框架本身确实是一种Provider框架，也就是让我们摆脱各种DAL的差异的束缚。从这个意义上，Linq就是一种通用的BLL工具库。你的自定义BLL类再调用Linq来补充其功能，甚至“表面层”直接调用Linq，都是更加强调了与DAL的解耦这个设计特点。