三层架构的查询问题。
最近刚学习了三层架构 ，在网上找了一个范例学习，在项目应用中遇到两个问题向大家请教：
我参考的范例：http://www.cnblogs.com/cresuccess/archive/2008/12/10/1351675.html

1. 通用查询问题
  如何实现通用的查询，针对各数据库表，不同的字段，不同的查询条件。
如：
select * from tab where name='张三' and sex='男' and birthday between date1 and date2 or .....



2. 表与表的关联
  表与表之间多数是通过ID进行关联的，如何能快速取得另一个表中的信息。
如：

table1: bid,name
table2: sid,bid,name

在操作table2的model时，如何更快捷地取得table1的name，只操作一个model.

不知道有没表达清楚我的意思，最好能提供相应的案例，谢谢。

------解决方案--------------------
你所说的跟三层架构没有直接关系。不管你从哪里个“范例”学个DAL写法，都是纠结于数据库表操作。而三层架构的含义，就是让你在设计表现层时不要去纠结于数据库表，根本不用去翻来覆去地纠缠什么DAL，而是抓住更重要的BLL层，仅仅设计表现层和业务逻辑层而不要纠缠DAL的写法。

你真的学明白了三层架构了么？

就算你使用最原始的ADO.NET的Sql语句，又有什么关系？仍然可能是非常清晰、通用、高效的三层架构。

虽然操作数据库方面可以有很多方式，包括面向对象数据库方式（而非关系数据库方式），但是这些都是局限在DAL里边。跟三层架构美欧直接关系。你所看到的所谓“范例”假设只是告诉你如何操作关系数据库表，那么它就好象是用发霉了的烂茶叶冒充新采摘的龙井茶一样，欺负你不会喝茶。
------解决方案--------------------
架构是死的，人是活得，完全按照框架做出的程序，恐怕只能在内存里组织“连对象查询”了，这对性能的影响很大，但这种查询量并不大，可以先用框架凑合出结果，后期在改进时在底层的数据层增加专用的连表查询方法，对业务层进行很小的改动即可，界面层不需要任何调整。
而如果在业务层写死sql语句方式，虽然“性能可以保持很高”，但初期编程很容易发生数据架构的变更，系统一大，往往把各个模块的程序员整的手忙脚乱，难免出差错。
------解决方案--------------------
如果你明知道数据库是sql server，那么写一个sql语句调用它就行了。别人爱用什么EF之类的就让别人去用好了。这对什么三层架构毫无影响！
------解决方案--------------------
2. 表与表的关联
表与表之间多数是通过ID进行关联的，如何能快速取得另一个表中的信息。

这完全属于sql的知识，和三层架构没什么关系

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

探讨

最近刚学习了三层架构 ，在网上找了一个范例学习，在项目应用中遇到两个问题向大家请教：
我参考的范例：http://www.cnblogs.com/cresuccess/archive/2008/12/10/1351675.html

1. 通用查询问题
如何实现通用的查询，针对各数据库表，不同的字段，不同的查询条件。
如：
select * from tab where nam……