大家来谈谈关于AOD.NET在三层应用中使用的位置

Question

表示层
                                  |
                               逻辑层
                                  |
                               数据层1、使用位置：在表示层与逻辑层、逻辑层与数据层间都使用ADO。NET来操作
   优点：各个层间传递的通常是dataset或datatable、datarow，表示层帮定数据到控件时很方便。2、使用位置：只在逻辑层与数据层使用ADO。NET
   优点：这种方式应该更贴进OO的思想
其它的方法没有使用过，所以就不罗列出来了，大家谈谈还有没有方法，每种方法各自的优缺点。

Answer 1

大家在表示层与逻辑层都使用的参数来传递?而没有:
1、先获得某个表的结构,
2、把参数存储在datarow中
3、传递datarow
吗？

Answer 2

我只在数据层使用Ado.net，我逻辑层都不用Ado.net的，而且微软的“业务逻辑”项目的默认策略就是不允许在逻辑层使用Ado.net的。你在“业务逻辑项目”（新建项目－其他项目－企业级模板项目－####生成块－业务逻辑）内使用ADO.net的时候系统会给出警告（不是错误，是警告）说策略不允许在项目中包含########。
我关于三层式的一些想法与介绍：(面向初学者)
http://dev.csdn.net/develop/article/68/68745.shtm欢迎讨论与指正。可以给我发消息或在我的blog上留言

Answer 3

1、使用位置：在表示层与逻辑层、逻辑层与数据层间都使用ADO。NET来操作
   优点：各个层间传递的通常是dataset或datatable、datarow，表示层帮定数据到控件时很方便。
缺点：
1 、上面优点的最后一点其实是缺点，表示层绑定数据并不方便，难道你建立一群ADO对象来获得一个DataSet，包括连接、执行、数据集、关闭、适配等。会比用:
Users theUser=new Users();
DataGrid1.DataSourse=theUser.GetMyInfo();
DataGrid1.DataBind();
3句话实现绑定更简洁？？
2 、代码可读性差，逻辑结构混乱，与其如此，不如不分层。
3 、数据库发生变革时（比如需求变化而改变数据库结构，或因正版费用问题而把Oracle换成Access等）需要做大量的查找与修改。2、使用位置：只在逻辑层与数据层使用ADO。NET
   优点和缺点：这种方式应该更比1贴进OO的思想，1和3之间的过渡。
3、使用位置：只在数据层使用ADO.NET
优点：比2更加贴近OO思想，更加体现现代编程的“高内聚，低外耦”要求，在数据库发生变革时可以完全不需要动业务层与界面层，实现“BlackBox”，同时保护数据结构。更有利于代码复用。
缺点：早期开发周期较长，但是随着发展，可复用部分渐多，开发周期大幅缩短。

Answer 4

我认为第二种方式比较好,/************************************/当逻辑层的某个类改变时,表示层也需要重新编译dll获取逻辑层的新接口;如何使用插件的方式来使用逻辑层的类(dll)呢?也就是说表示层不需要编译就可以选择逻辑层的类(dll)?