瘦BLL+胖DAL VS 胖BLL+瘦DAL（1）

简介

＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝

以前做过一些winform的项目，那些项目也涉及到数据库，但是那些项目中表的作用只是把那些数据管理起来而已，

表与表之间的关联，或者说表与表之间一般不会有什么多表查询，为什么我会在这里说到多表查询呢，因为这个问题

就是我写这篇文章的原因，这里只是想起一个提出问题的作用，也希望大家帮忙帮忙。。。我做web还没有一个月，

就遇到一个问题，这个问题应该是很多人都有的，我这里集合我找到的一些资料和网上的讨论，仅仅想起到一个抛砖

引玉的作用。。

＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝

 

问题

＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝

任何做过web的程序员，一定知道三层构架，也就是什么界面层，业务逻辑层和数据访问层，界面层这里

就不做为今天的主题，我就来说一下业务逻辑层与数据访问层与处理多表查询之间的矛盾。

我这里引用别人的例子，我做了上点改动。

举例说明：
我有一个公司的管理系统，其中有两张表Department和Employee，现在公司有个需求说需要查看某一部门员工列表，

要求要有部门名称。我首先是建立两个实体类，DepartmentInfo和EmployeeInfo，其中EmployeeInfo中有一个

DepartmentName的属性。 然后我的做法是在DAL层中的Employee类中加一个方法

public List<EmployeeInfo> GetEmployeeList()
{

//string command="select e.*,d.departmentname from employee e,department d where e.departmentid=d.departmentid";

//或者调用存储过程

//.....访问数据库，填充EmployeeInfo
}
然后在BLL层中也写一个方法

public List<EmployeeInfo>  GetEmployeeList()
{

     DAL.GetEmployeeList();

     //......一些其它的处理

}
最终在UI层去调用BLL的方法去实现列表显示。

在上面的程序示例中，DAL层中不论是直接用SQL语句还是用存储过程，这样无形之中就将业务逻辑转嫁到了数据访问层，

数据访问层是干什么的，数据访问层应该仅仅是对数据库进行访问，他才不管你什么业务逻辑，这样不就乱了吗？？如果表的连接

越多， 这种现象也就越明显。

好，为了不乱我就想一个办法，不就数据访问层吗，分层就分层，

BLL层：

public List<EmployeeInfo> GetEmployeeInfo()
{

//先得到员工，DAL.GetEmployee();

//再得到员工所在我部门名,DAL.GetDepartmentName();

//最后填充EmployeeInfo
}

DAL层：

public List<Employee> GetEmplyee()

{

     sql="select * from Emplyee";

     //操作emplyee表
}

public string GetEmplyee()

{

     sql="select DepartmentName from Department where DepartmentId=123";

     //操作Department表
}

这样就完全是按三层做的，并且这样的代码可以用代码生成工具生成，但是这样的代码在效率上就不成样子了，这样就有

了问题，怎么解决呢？用不用三层呢？？

晚上，再写一些我的想法，先吃饭去。