多表查询应该分到三层架构的哪一层？

那你多表对应哪个实体呢？在添加个实体类？建立个DAL.cs?其实也没必要一个实体对应一个类有的时候别的类操作的时候需要另外一个实体。数据库访问都放在DB层访问就行了->数据库交互

楼上已经有人回复了，很正确，我再简化一下。其实有些.net（贴了微软牌子的）“范例”把三层严重地复杂化了，甚至变成了为了三层而三层。这些年，微软也推出了很多简化编程、提高灵活性的机制，不管这些好用不好用、性能够不够用在生产环境，总之是跟那些范例大大不同的。其实看看所谓三层它针对什么，就明白了。过去的“两层”，就是在前端程序中直接操作数据库，而没有把“企业服务”独立出来。当你把企业服务独立出来，能够给各种各样不同应用来使用，甚至可以跨不同的前端平台，例如javascript、silverlight、winform、asp.net、java甚至php都可以访问，桌面、手机机顶盒、互联网电视都可以通过服务的几种简单的联网方式来接入，是比较典型的三层架构概念。假设你不精通（小型）电信级的通讯知识，至少可以把业务服务功能作为你的多款前端界面貌似不同的asp.net、winform等程序通用的共同引用的BLL工程来使用，例如你的asp.net做得“人事管理系统、业绩管理系统”跟wpf做的“呼叫中心系统、贸易订单系统”等等许多子系统使用同一套BLL类库，这也是在实践最简单的三层概念了。而至于你如何实现，其实也不必求完全一致。只要知道为什么要分这个层就好了。三层系统，是最简单最原始的一种分层概念，是进行稍微大一点的系统设计的初步知识，不要把它当作什么很高级的东西。

实际上假设你没有那么大精力去做前端，你可以把几十款前端都外包给个人去做，甚至同一个前端可以找不同的人、不同的开发工具去做，然后你可以挑一款用户体验最好的发布。而在业务逻辑部分，你可以针对业务接口进行系统权限控制，维护系统一致性，处理核心业务，使用许多台服务器来处理大量负载（假设有1000个客户端正在执行3000个前端应用，你肯定需要将业务处理服务器从一台增加到3台以上），所有这些逻辑上的重新设计和服务器架构调整你都无需通知前端开发人员，它们也不需要关心后台用的是什么数据库、用没有用数据库、负载均衡怎么解决，它只知道服务器的业务服务比较可靠、性能可方便地提升、发布新的企业API接口非常方便，这就行了。这就是所谓的三层架构的最基本的效果。

所以教条或者不教条，都不一定是你首要要去争论的。搞清楚你的BLL层能不能跨自己的不同前端系统，这就是最好的三层的证明。假设你在asp.net中搞了很多个目录、放了很多个用BLL或者DAL打头起名的文件，可是你的BLL根本不能从前端程序中剥离出去作为一个独立被设计、开发和维护的工程，那事实就证明你的三层可能是有害的了。而既然BLL独立设计了，前端程序可以根据BLL接口API文档就单独开发和（用 Mock 方法来）测试，还用担心DAL在哪里写吗？我对DAL基本上不做要求，因为它是很次要的东西，这可以留给不同的人去争论DAL教条如何制定问题。反正此时你已经做到三层系统了。

SORRY是我问错了你们都理解错了。我的意思是比如多表查询我应该放在DAL的那一个类。因为本来是一个表对一个类现在多个表如何分类

对数据库的操作都放到数据访问层（DAL）

如果你是用面向对象的方法设计实体，你就应该放入会员基本档案类的dal层，因为会员等级情况表
从属于会员基本档案表。

搞清楚你的BLL层能不能跨自己的不同前端系统，这就是最好的三层的证明。
这个这个非常好。

多表查询写成视图view，view生成实体。
根据实体在业务层写代码，就这样了

class 用户表{
int ID;public 用户等级实体 GET(){
DAL_用户等级.GET_BY_ID（this.ID);
}
}

多表查询写成视图view，view生成实体。
根据实体在业务层写代码，就这样了
======================
实用

可以生成一个特定的视图，然后用DataTable进行绑定数据
至于非要用载体类的知，类可以用面对对象的方法进行创建。

建一个DAL层,其他的写在BLL层中

放到数据访问层吧，针对SLQ语句对应的类里！

好像没人说一个实体类对应一个DAL类

呵呵，我第一感觉放到BLL，悲剧。因为觉得多表查询涉及业务需要
不能因为多一个业务需要就去修改DAL
看看各位大牛的观点，好吧，我错了

多表查询分层
首先，多表查询，你可以做成视图（View），然后针对视图做实体类，实体类定义要具有实际意义。
DAL就可以针对此实体创建数据访问类了。
这样比较清晰。

本来都是一个实体层对应一个数据访问层
---------------------------
对实体类的操作应该有业务层来做，而实体类的持久化和查询等基础功能应该由一个“基础设施层”来做；数据访问层，应该放置各种复杂的SQL查询，它的作用就是管理SQL并获得查询结果，提供方法供业务层调用。
给你一个应用的架构图，注该架构使用了PDF.NET框架作为数据框架，应该算是基础设施层。

楼主放哪里的啊我估计理解你说的放数据层（DAL）就是些 SQL 语句比如外联内联如果写 BLL层就是 BLL层之间直接的调用不过我觉得两种做法都可以看你喜欢那种比如喜欢或者说很熟悉SQL语句的当然是 DAL层好如果熟悉ADO.net 我觉得还是放 BLL，而且我觉得 DLL层内部调用后访问数据库也许会更好点

DALUserBLL.GetUserInfo(int ID) // 用户信息
UserBLL.GetUserRank(int UerRankID) //用户级别
BLLUserBLL.GetUserInfo(int ID) // 用户信息
UserBLL.GetUserRank(int UerRankID) //用户级别页面上要调用用户基本和信息写一个 UserBLL.usInfo()
1.用SQL 关联 UerRankID 从读出
Select * From UserInfo i inner join UserRank R On i.UerRankID=R.UerRankID and UserID=1232.用临时表（暂时这样叫）

UserBLL.GetUserInfo(int ID) // 这里返回假如是 UserInfo实体int UserID=123UserInfo Us=UserBLL.GetUserInfo(UserID)string UserRank=UserBLL.GetUserRank(Us.UerRankID)DataTable Dt= new DataTable();Dt.Columns.Add("UserName",typeof(System.String))
Dt.Columns.Add("UserRankName",typeof(System.String))
.....
.....
Dt.Columns.Add("UserTel",typeof(System.String))DataRow DtRow = new DataRow();
DtRow["UserName"] = Us.UserName;
DtRow["UserRankName"] = UserRank;
....
....
DtRow["UserTel"] = Us.UserTel;
Dt.Rows.Add(DtRow);
其实最近发现有同事和我都遇见这样问题他们做法基本都是用SQL语句我就是第二种方式，再写一个静态类静态方法直接调用就可以不知道楼主是不是说的这个意思

楼主主要是想问:如果关联两个表,那么实体类该如何建立.
一个User表和一个Group表关联的话,我们建立一个User类,建立一个Group类.
但我如果想查询UserName和GroupName,那么我们是不是还要建一个GroupUser实体类呢?
有两种办法:
方法一、建立视图,返回一个DataTable.(没必要为每个视图建立一个实体类,如果视图改变的话,建立的实体类也要变化,太复杂)。
方法二、建立实体类时,可以这样建立:public class UserModel
{
public int UserID { get; set; } public string UserName { get; set; } public GroupModel GroupInfo { get; set; }
}public class GroupModel
{
public int GroupID { get; set; } public string GroupName { get; set; }
}让User实体类持有一个Group实体类的引用,这时候,我们获取UserList时,就可以使用UserName和GroupName了.如果还有其他的关联,则可以再持有其他的实体类.

调试易

多表查询应该分到三层架构的哪一层？

解决方案 »