有人告诉我，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如果有关联查询的对与以后扩展是很麻烦的
如果不是的话
这样似乎是没效率的
一一对应的表和实体
这样似乎有很有些不对
实体的属性是另外一个实体怎么办？？
------解决方案--------------------
但是这样导致的就是性能大打折扣
哎
我一直很纠结这个问题
-------------
楼主不要结贴
已经各推荐了
等人高手来看看怎么办
呵呵
------解决方案--------------------
我的做法跟 lz 差不多，自己写了 DataModelManager 来完成 ORMapping 的工作，
其实就是 lz 说的“DAL使用了泛型和反射实现了一个数据访问工厂”，其实跟 LINQ 做的事儿差不多。
至于多表联合查询，其实质是对象的多个简单类型属性及对象类型属性进行复杂查询，
而多表联合查询是利用关系数据库的特性，将对象的复杂查询的扁平化，以提高查询速度！
我设计了一个 QueryConditionString 类，用于动态拼接 Where 语句，
多表查询时，必须写入表名，以标明所属的表，而 select 是事先在 DAL 中写好的，
查询结果会被封装为 List<BusinessModel> 返回。
至于纯对象的复杂查询我也尝试过，确实比较麻烦，而且数据量较大时，性能方面确实存在一些问题，
还没来得及研究优化方案。