linq to sql如何分层

[yaotomo]

使用LINQ to SQL后，Model层就和DAL层到一起了，在DAL层中使用datacontext向BLL层返回实体对象时，类型为List<DAL.EntityName>，再返回给UI层，还是LIST<DAL.EntityName>类型。但是按原则在UI层是不允许引用DAL层的。请问应该如何解决？
网上有的说应将DBML单独分层，DAL调用其datacontext，这种方式好吗，感觉复杂度提高了，效率上没提高多少。。

请各位老师指点。

[夜色镇歌]

LINQ to SQL就是一个DAL啊。

[threenewbee]

你设想下，你可以在不修改BLL的情况下，把Linq To SQL改写成完全使用ADO.NET的实现么？如果你做到了，你分层就成功了。 分层本身就是增加复杂度，降低性能，换来提高适应性的举措。

[夜色镇歌]

用EF吧。

[三五月儿]

引用 1 楼 a346729576 的回复:

LINQ to SQL就是一个DAL啊。

同意

[will_stier]

引用 2 楼 caozhy 的回复:

你设想下，你可以在不修改BLL的情况下，把Linq To SQL改写成完全使用ADO.NET的实现么？如果你做到了，你分层就成功了。 分层本身就是增加复杂度，降低性能，换来提高适应性的举措。

BLL层的目标就是不理会数据库？。明白了。

[以专业开发人员为伍]

引用 楼主 yaotomo 的回复:

但是按原则在UI层是不允许引用DAL层的。请问应该如何解决？

不懂这是什么原则啊？

[以专业开发人员为伍]

基本上你在.net中找到的所谓DAL框架往往都是为了面向对象的，是相当高级的目的而开发的，它原本就是为了通用化的目的的。你只要注意在UI层不要使用DAL就行了。 基本上，具有BLL层的程序是为了能够通过修改业务层来直接改变UI表现。这个角度是让UI的设计根本不用考虑“有还是没有数据库”的问题。你应该现在内存的List<T>中模拟数据，就开发好BLL层的接口，以后在接口不变的情况下才逐步考虑是否使用数据库的问题。

[以专业开发人员为伍]

引用 5 楼 will_stier 的回复:

BLL层的目标就是不理会数据库？。明白了。

考虑使用EF或者别的什么ORM系统（作为你的DAL框架）的时候会以这个目标。但是BLL层的目标是为了跟UI层做到业务功能上的对应，比如说UI上有一个“小区内各个电闸的运行状态”的图形系统，那么你的BLL层往往就需要一个对应的用来查询和修改电闸运行状态的数据支撑系统。 BLL的目的最主要地是希望UI层可以用各种不同的前端开发工具来开发，而不必在前端程序中写什么业务逻辑程序，而是尽量傻瓜化地跟业务服务器的api绑定就行了。 不过如果你写一个asp.net程序，或者就是那种调用关系数据库的客户端驱动的简单winform程序，此时考虑“三层”往往是没有定型的，往往理解不了BLL的目的。只有多做几个服务器系统，例如Tcp或者Web服务器系统，给不同的客户端（例如.net和java的客户端同时）访问，才有了BLL层概念。 在交互复杂的UI程序中（例如一个漂亮和功能丰富的winform程序），去纠缠于三层概念往往会导致错误的架构。因此这种程序注重的是前端进程内几十个、上百个模块的协调开发。如果你认为每一个模块都各自为政地自己去访问BLL层,那么模块之间如何通讯呢？如何灵敏地自适应呢？如何按照接口逐渐开发和重构UI控件呢？这才是UI程序开发的重点。 有人以为前端每一个模块都是把自己的数据“增删改查到服务器”然后别的模块再去查询，这样显然纠结于“三层”反而是个祸害，简单的三层概念反而倒这样的人不重视前端程序架构设计了。

[will_stier]

引用 8 楼 sp1234 的回复:

[quote=引用 5 楼 will_stier 的回复:] BLL层的目标就是不理会数据库？。明白了。

考虑使用EF或者别的什么ORM系统（作为你的DAL框架）的时候会以这个目标。但是BLL层的目标是为了跟UI层做到业务功能上的对应，比如说UI上有一个“小区内各个电闸的运行状态”的图形系统，那么你的BLL层往往就需要一个对应的用来查询和修改电闸运行状态的数据支撑系统。 BLL的目的最主要地是希望UI层可以用各种不同的前端开发工具来开发，而不必在前端程序中写什么业务逻辑程序，而是尽量傻瓜化地跟业务服务器的api绑定就行了。 不过如果你写一个asp.net程序，或者就是那种调用关系数据库的客户端驱动的简单winform程序，此时考虑“三层”往往是没有定型的，往往理解不了BLL的目的。只有多做几个服务器系统，例如Tcp或者Web服务器系统，给不同的客户端（例如.net和java的客户端同时）访问，才有了BLL层概念。 在交互复杂的UI程序中（例如一个漂亮和功能丰富的winform程序），去纠缠于三层概念往往会导致错误的架构。因此这种程序注重的是前端进程内几十个、上百个模块的协调开发。如果你认为每一个模块都各自为政地自己去访问BLL层,那么模块之间如何通讯呢？如何灵敏地自适应呢？如何按照接口逐渐开发和重构UI控件呢？这才是UI程序开发的重点。 有人以为前端每一个模块都是把自己的数据“增删改查到服务器”然后别的模块再去查询，这样显然纠结于“三层”反而是个祸害，简单的三层概念反而倒这样的人不重视前端程序架构设计了。[/quote] 谢谢。 还想问下， 我现在就在试图做一个教学管理系统，可以自定义课程的。 我的理解就是，在BLL层，“尽可能”的提供各种访问数据，以及逻辑上的API。 在WebSite中如果涉及到和页面UI结合比较紧密的逻辑处理——如果不便于在BLL中编写，就在 页面中编写——此时不需要纠结分层问题？

[moonwrite]

用EF EF可以生成实体类文件 每个实体一个文件 又有Dbcontent， 可以把Dbcontent复制到Dal中去