也问三层架构的问题。
对三层架构一直没有真正理解，尽管用过三层架构来开发。看过一些关于三层架构的帖子和例子。看过后越发不明白。
我想通过一个具体的例子，请教一下三层架构的基本思想。
比如：我要做一个导航页的程序：
我的想法是：
1:在表示层将查询条件(where   key= 'a '   and   contractid= 'aaa111 '   等),当前页码,每页大小,查询的表明(tablename),主键(primarykey)等作为参数,带入业务层相应的类的方法中.
2:在业务层中再调用数据层的实体类,传递上述参数.
3:再数据层有一个页码导航类(通用)根据产地过来的参数,调用数据访问类,获取查询数据的总行数(第一次查询时获取),并且获取相应页码的数据.然后将获取的数据以DataSet的形式返回给业务层.业务层再将数据返回给表示层,在表示层里将数据绑定导控件中.
我原来开发是将实体类部分放到业务层中,但看过一些例子大都将这部分放到数据访问层中,对业务层的功能比较迷惑,另:大部分例子中SQL语句是在数据层里面构造的,我在表示层里面准备的参数:   直接写where的条件串(而不是在数据层里)及表名是否也不符合三层架构的规则?
另:希望网友能给一个非常简单的例子说明一下三层的关系.谢谢.




------解决方案--------------------
表示层写WHERE子句,不太合适.
表示层的程序员没道理没理由没义务没权利子解数据库的结构,如表名,字段名...

可考虑在实现层为业务实体定义一个结构体,传查询参数时,用这个结构体包装.
------解决方案--------------------
我觉得啊。。
----------------------------------------------
然后将获取的数据以DataSet的形式返回给业务层
----------------------------------------------
各层直接最好别用DATASET传递。。.net2.0 的泛型加实体。。是比较好的选择。。也比较符合ORM思想
------解决方案--------------------
各司其职

看看三层结构的各层的名字
------解决方案--------------------
个人认为`~``

现在很多人写三层 都是一个空架子
仅仅只是WEB层 和数据访问层 这2层
其他的都是没必要写的
比如逻辑层 逻辑事物处理的地方 仅仅是一个空壳
------解决方案--------------------
ls所言并不尽然
------解决方案--------------------
用的人不同,效果也不同

------解决方案--------------------
不要再问了，自己写这方便就可以了，越问越乱。

因为根本就没有一个统一个规定。尤其是对于web开发来说。

因为现在的都是在软件的基础上来说的，软件的业务逻辑是很复杂的，web得很简单。所以就有了总总分歧。


------解决方案--------------------
我是说，每个人都有自己的理解，你说你的，我说我的，各种想法交织在一起，就乱了。

我是一直用我的想法，当然也会参考一下其他的想法，但是会以我的想法为主！

如果你不怕晕的话，看看这个

http://community.csdn.net/Expert/topic/5397/5397049.xml?temp=5.028933E-02

http://community.csdn.net/Expert/topic/4949/4949724.xml?temp=.5192224

http://community.csdn.net/Expert/topic/5383/5383707.xml?temp=.4649011
------解决方案--------------------
关键是在于代码的复用性，团队间的协作性，共享性，可维护性，扩展性，还有就是项目的大小性
最后，关键的还是个人的理解性！
------解决方案--------------------
可以先做然后再争论，在 SqlDatasource 和 ObjectDatasource 之间选择一个作为ui程序必须的组件，先写好程序。
------解决方案--------------------
例如我们总往Session集合里放对象，但是Session在基于内存机制里总是会有麻烦的，在状态服务器或者SQLServer机制里却需要在服务器上另外开启和维护其它的服务，为什么我们不能换一种具有数据库永久保存对象的功能的Session？

大多数人会说：因为微软没有提供。

其实如果微软没有提供，我们就自己动手做嘛。如果你开发得稍微底层一些，就可以领先于许多人。例如你的Session项目数据总是保存得很好，不会被技术争论带来的不可靠性所拖累，不需要要求web服务器上开启什么额外的服务。

如果你解决了将对象不需要拆开成SQL命令就直接操作到数据库里的问题，你就会想如何直接把它使用到ui程序上，而不需要用关系数据库作为表示形式。

没有办法，必须重复用个真实的代码才能说得清楚。假设要把一个单位用车记录保存进数据库：


DateTime 使用时间=.....;
.......
using(Domain dm = LocalDatabase())
{
员工 p=dm.Select <司机> ( "老张 "); //按照姓名查询
汽车 c=dm.Select <汽车> ( "AS232323 "); //按照车牌号查询
用车记录 rec=new 运输记录( "2007-3-30 ");
rec.司机=p;
rec.car=c;
c.最后使用时间=使用时间;
dm.Save(rec);
dm.Save(c);
dm.Commit(); //默认地关闭dm的时候也会自动Commit。
}


关系数据库在过去20~30年的发展相当成熟。关系数据库告诉我们：我们的对象必须拆开成一个一个单独的类型定义、字段定义、索引定义、级联关联定义等等离散的并且及其简单的值类型对象，也没有处理继承、接口的能力，查询总是需要使用join运算而不能按照对象之间的关系网直接查找。

但是反之，如果你已经考虑使用面向对象的方式作为数据库接口，就干脆把ADO.NET当作鸡肋吧。