让人纠结的三层架构
有人告诉我，DAL里不能出现任何业务逻辑，并且具有可重用性。
有人告诉我，BLL里不能出现任何SQL语句和事务。

俺疑问的是，多表关联查询呢该放在哪儿呢？别告诉我用视图。

------解决方案--------------------
DAL 负责 多表关联查询的SQL生成和执行
BLL 负责 将业务条件转换为DAL的数据条件，BLL还要检查用户权限、添加用户数据限制等。。
------解决方案--------------------
不用视图的话，BLL负责组织多个DAL之间的联系。
BLL只是负责调用DAL，并不会出现SQL语句。
事务的开启和结束在BLL里面定义出现实际。
------解决方案--------------------
DAL并不是与表和视图一一对应的。
可以定义一个DAL，DAL.Query里面的SQL写多表查询，这个DAL就不对应数据库中的表或者视图，而是一个SQL语句。
------解决方案--------------------
多表关联 是一种数据关系
比如表A和表B的外键关系

而业务逻辑关心的的是业务对象之间的关系

比如 用户需要查询 某小区的房屋
那么业务逻辑 进一步明确为 此用户可看的 已审核的 房屋信息 且是某小区的

而数据逻辑 进一步明确为 查询 房屋信息表 条件包括：对应房屋审核表中状态为已审核，对应小区表中 小区编号为AAA，对应 房屋访问权限表中访问人为 此用户
------解决方案--------------------
呵呵，别拘泥。

业务逻辑可以出现任何一层，判定标准是开-闭，如果就他自己用，为啥不可以封闭呢？
比如订单流水号的生成，需求要求生成有规则的且唯一的编号，这该算具体业务吧！那他为啥不能在dal里实现？？

别太拘泥就成，OO关注抽象，关注变化和变化的速度。 实际上很多细节处理放在任意一层都可以，这个并不是OO的关注的核心。
------解决方案--------------------
三层的意思就是在表现层不出现任何数据库概念，而只与中间业务逻辑层绑定对应关系，这就是三层。
------解决方案--------------------
wanghui0380：
呵呵，不是拘泥的问题，对新手来说，划清这个界限很重要，要不然永远体会不到3层的必要性
就比如你举的例子：
//需求要求生成有规则的且唯一的编号，这该算具体业务吧！那他为啥不能在dal里实现？？

这个里面需求是：生成有规则的且唯一的编号
业务规则可能是：单据类别（2位）+日期(8位)+流水号（4位数字）
TA201012100001
而数据处理时，可能会把这个字段拆成3个字段存储（应根据数据存储、查询、性能等要求）
而流水号的分配也有很多中分配方式，数据库自动增长、存储过程分配、。。。

所以将BLL和DAL严格区分很有必要，将来换了流水号的分配方式就不用变动BLL层
------解决方案--------------------

这个问题我也一直很疑惑

sql如果有关联查询的对与以后扩展是很麻烦的


如果不是的话
这样似乎是没效率的
一一对应的表和实体

这样似乎有很有些不对

实体的属性是另外一个实体怎么办？？

------解决方案--------------------

探讨

引用:
你的意思是说为了获取一个DTO可能会通过获取多个Entity来获得 获得多个Entity 每个Entity查询一次？

这是我的理解，不一定对哦。

------解决方案--------------------

探讨

还有一点，为加快前期开发速度，以及适应项目不断调整的需要，俺的DAL使用了泛型和反射实现了一个数据访问工厂，但对于多表关联查询支持很弱，希望大家能提出好的解决方案。