一个关于三层架构代码该放哪儿的问题...困惑了我好久啊...
先上图
如何,这是一点逻辑操作代码,用来判断登陆是否成功的,
现在我的问题是,这段代码要放在这儿(逻辑层)好,还是放在数据层??还是表现层?
还是要怎么做才好??
如果接下来还有复杂的算法逻辑,那怎么放??
我都晕了.........纠结了好久啊 算法 架构 数据 --------------------编程问答-------------------- 你自己都说是逻辑操作了还不懂吗？
--------------------编程问答-------------------- 如果你能想明白为什么要分层这个问题，“放在哪里”这个问题就想明白了。 --------------------编程问答-------------------- 放在逻辑层（BLL） --------------------编程问答-------------------- 如何,这是一点逻辑操作代码,用来判断登陆是否成功的。
--------------------------------------------------------------------------------
楼主，三层的作用先温习一遍吧，我觉得逻辑操作未必是放在逻辑层 --------------------编程问答-------------------- 维持现状就行了.
LZ的注释写得不规范。应该用xml注释。 --------------------编程问答-------------------- 放在底层！！！！ --------------------编程问答-------------------- 什么意思? --------------------编程问答--------------------
--------------------编程问答--------------------
其实，根本就没有你这么写代码的。你设计了一个Use的类，
然后又通过这个类获得dataSet，
然后从DataSet的table里面查找对应的用户，
然后再去判断密码。
你累不？
另外很奇怪的事情 —— 如果没有登录成功，那么你的Use的实例是怎么得到的？user.UserID 是谁？
在另外，为啥要把密码提取出来放到dataset里面？而且貌似没有加密。（后面的代码没有截取出来，所以是猜测）。
--------------------编程问答-------------------- 如果用上AccessDataSource,SqlDataSource或XmlDataSource控件的话，也许只是放在aspx.cs网页内了。
有关此类判断，你在可以放在数据库层，也可以放在逻辑层，也可以写在网页(不使用上面列举的控件)。
这要看你的程序设计了。
--------------------编程问答-------------------- 你们把DAL写成DAO啊 --------------------编程问答--------------------
DAO是另一个东东，和DAL有点交集，单肯定不是同一个。 --------------------编程问答-------------------- 什么是三层，为什么要用三层，三层有什么作用，三层要怎么用才能体现他的效果。你先搞清楚这些吧 --------------------编程问答-------------------- 要不然到以后，就算你用三层很熟练了，但是你不知道他为什么要这么用，这个为什么用到这个层中。那你的技术水平还是不会有进步 --------------------编程问答--------------------
这种问题确实要自己理解了。要不然别人给你说无数次你也无法啊理解。我的博客中有一个资源，希望对你有帮助 --------------------编程问答-------------------- 如果你能想明白为什么要分层这个问题，“放在哪里”这个问题就想明白了。 很显然 楼主你贴的这段代码是DAL层的，你写的这种验证登录你这里BLL逻辑层没有需要处理，传个usermodel到底层 返回出来就行了！ --------------------编程问答--------------------
user这个对象是用来记录UI层上传进数据库的数据,不是从数据库回传来的,回传的放进DataSet..也就是说无论登录是否成功,跟user对象没关系 --------------------编程问答-------------------- 有一种很能扯的DAL，就是把逻辑操作都放到DAL里。这种所谓的教条，害了许多人。形式上，它就是差不多8、9年以前的PetShop代码的DAL的样子（微软有上万个类似的小项目，各自用了不同的方法，不是只有PetShop的代码才叫做三层，可惜很多人没有看懂这个项目的BLL，而仅仅记住了DAL）。
实际上现在.net framework的DAL有了突飞猛进的改革，不但支持泛型、lamda等等，甚至支持自动代码生成。因此就比较容易区分你的这个问题了——基本上你不应该再自己写DAL层代码。
除非你正在研究一个比微软的（比如说） EF 等框架更强大的框架，你这个时候研究的自然就是独立的 DAL 层代码。否则你就没有再去写什么 DAL 层代码。
如果你还像有些人那样只写一个“薄薄的”BLL层，而将类似“判断Password，然后返回true/false”这种东西也叫做DAL，这显然是滥用DAL的。
如果需要选择“累赘一点还是精简一点”，我给出的选择就是：你再也不要写DAL层代码，仅仅在自己的BLL层代码中调用各种现成的DAL框架就好了。充其量，你可以自己写一个非常通用和简便的SqlHelper作为DAL（而这个DAL中你在定义各种业务模型“之前”就已经给出DAL操作定义了）。 --------------------编程问答-------------------- 通常，仅仅会点asp.net的人可能更容易曲解“三层”概念。因为asp.net程序本质上就是单机程序，而不是一个“客户-服务器”需要分层设计的程序。在这些人中有一半的人都可能随随便便地、理直气壮地把BLL代码写到DAL里，这就不足为奇了。
不过为什么这种混乱可以持续好多年？因为比较重要地是要强调BLL层的接口协议设计问题。而对于滥用DAL我们可以懒得去争论。
但是如果你发现写一堆什么“LoginDAL、UserDAL”纯粹是劳民伤财的累赘的，我也非常乐见你有这个精简而更实用的改变。 --------------------编程问答-------------------- 最好是放在BLL 层吧。
如果不包含任何逻辑的代码， 可以直接调用DAL而无需写BLL层。
但不建议放在 aspx.cs 中， 这是最差的做法。 会让页面臃肿难以维护， 代码可读性和可维护性都变差。
--------------------编程问答-------------------- 写一个“薄薄的”BLL层代码，而DAL层代码是根据业务对象来一一写的，然后什么BLL操作都传递给DAL层代码来执行，那种所谓的“三层”没有灵活性。最终，你不得不经常自欺欺人地说“表现层要调用业务逻辑也可以直接调用DAL啊”，这样直接就跟三层的作用矛盾了的。
这种紧密耦合业务模型的DAL层的根据，是非常地生硬的。“如果有一个User业务实体，那么我就要写User的‘增删改查’四个操作啊！如果数据库底改变了我就要修改DAL层代码啊。有个这个层就可以修改数据库底层的实现机制啊”。
你修改关系数据库处理基本机制，就发现此时必须需要SqlHelper层或者改变EF或者ORM或者直接改变ADO.NET 的DbFactory返回值才行。那么你就在所谓的DAL层下面用到了真正的数据库层了，你需要寻找比较好的类似 EF 或者 ORM 之类的抽象层，或者干脆就先不管这一层而直接调用ADO.NET或者MongoDb驱动之类的。但是总之，没有必要把这种数据层跟业务逻辑紧密藕合起来。
因此如果你有很多数据层框架可选，那么就不要写什么DAL层。省出时间去研究表现层和业务逻辑层吧。 --------------------编程问答-------------------- 我有一个项目，要从MySQL迁移到MongoDB，大概有800多个地方需要修改。在编译器（感谢c#编译器还是比较快速的）和自动测试程序集的帮助下，我用了两天时间就改完了这800多个地方，而且直接非常有信心地就发布部署了用MongoDB的版本。
这确实是在没有ORM的情况下。如果有一个ORM，相信要修改的地方不超过100处。但是这样一个好用的ORM比较难得，特别是性能足够高、而且还同时适配MySql跟MongoDB的ORM，还是很少的。因此我没能用上。
假设所谓根据每一个业务实体搞的DAL，我要重构产品，是不是要跑到DAL层里去也去修改800多处代码？
是的。因为那种DAL纯粹就是BLL，根本就是一个标题党。那种DAL下边仍然调用各种新颖的数据层框架，那种DAL被你用来重复地写业务逻辑的。 --------------------编程问答-------------------- 很明显，楼主的设计关注点分离不明确，我们看到你所谓的BLL层干了部分DAL层才干的事情，这么给你说吧，如果没有能够说服自己的理由，我们并不希望你的DAL层返回DATASET或DATATABLE，你的设计很明显是偏离了我们的预期。
我们所希望的BLL层，只与业务本身有关，与UI层或者数据库结构毫无关系。我看到了你把数据库结构与系统紧耦合在一起。我觉得你的userDAO,SelectUser方法返回值应该是User类型，返回查询出来的第一条记录，关注点放在细粒度的数据行上，而不是粗粒度的数据表。
我们的系统不论何时都不能过于依赖数据库结构，DAL就是用来降低数据库结构对系统的影响，理解了这些，你自然知道你的代码该放在哪里！ --------------------编程问答-------------------- “与UI层或者数据库结构毫无关系”这是含混的。
与UI层无关那是自然，三层就是这样告诉你的。而“与数据库结构无关”，什么叫做“数据库结构”呢？比如说ADO.NET本来就是具有抽象层，只不过大多数人懒得（而且也确实没有必要）去使用 System.Data.Common 命名空间的方法而不是 System.Data.SqlClient 或者 System.Data.OracleClient 等命名空间的方法。人家的数据库框架本来就是抽象的，各种数据库框架进行了许多“与数据库结构无关”的革新。
但是你把每一个业务实体都搞一套所谓的DAL类，这就是你做到了“与数据结构毫无关系”了吗？真要是将MySQL切换到MongoDB，你不是靠人家的底层的数据库框架（例如使用到了EF）、或者（如果你能够的话）自己开发ORM等机制来做到的嘛。
标题党地封装出一层名曰DAL的东西，是准备自己开发研究自己的ORM层框架？对不起，我相信你没有这个能力。于是这个DAL在我看来就是用来消磨时间的。而且我没有看到一个模仿早期PetShot式的所谓“三层”的团队能够据此提高生产率的，相反地只是一些学究用来消磨时光、成倍增加代码行数良好借口。 --------------------编程问答-------------------- 我们都知道，你在UI层的代码实现里就应该直接调用业务逻辑层的接口机制（这在c/s上通常叫做客户端网关）
你能说“UI层与业务逻辑层毫无关系，所以不能调用业务逻辑层的接口”吗？不会的。
可是怎么就说“BLL层与数据库结构毫无关系，所以就不能调用数据库框架的驱动”呢？
我认为这是因为这样的团队整天把时光消耗在数据库“增删改查”上，实在是对不起老板的怀疑的目光，所以干脆把数据库的增上改查贴上多一些的“业务操作”的标签，多分出几个层出来，好尽量把工作做得冗余拖沓，尽量拉长项目中数据库层的建设周期（而避免今早从高层入手去进行改造）。
我敢放言做出先入为主的判断，那些“为了三层而三层”的团队所谓的BLL层，大致也就是数据库单个表的“增删改查”，根本不是什么BLL层。 --------------------编程问答-------------------- 写了好多了，说的很明白了。 --------------------编程问答-------------------- http://www.dtcms.net
这有一个三层架构的反面教材 --------------------编程问答--------------------
哇。。。看着还挺正规的，怎么成反面了 --------------------编程问答--------------------
因为我是想DAL层返回来的有可能是一整个表甚至几张表，所以不知道怎么返回，就用了数据集了 --------------------编程问答--------------------
你看看那个BLL就知道了，完全是多余的。 --------------------编程问答-------------------- 除 --------------------编程问答-------------------- 1表现层，界面，简单判断
2逻辑，数据判断，复杂判断，返回成功失败，承上启下。 你放这里
--------------------编程问答--------------------
你也太逗了。
user这个对象是用来记录UI层上传进数据库的数据？？
那么 user.UserID 是怎么弄出来的？UI层传递过来的？是用户输入的还是……想不出来，不会是用户手敲出来的吧。
--------------------编程问答-------------------- 一切逻辑都是BLL --------------------编程问答-------------------- 放在逻辑层，这是逻辑判断 --------------------编程问答--------------------
select case kind when 1 then '保存' when 2 then '提交' when 3 then '通过' when 4 then '驳回' end as kind
这个是啥呢？ --------------------编程问答-------------------- 有人研究过TheBeerHouse项目吗 ？ 感觉是不是也是反面教材呢 ？ --------------------编程问答--------------------
--------------------编程问答--------------------
这个user.UserID就是UI上的一个输入框的数据啊,登录的时候用ID登录,这时候就记录下这个数据..我把同类数据都归在一个对象的属性里,user是对象,UserID是这个对象的一个成员属性,还有UserPassWord,一并存进去
补充：.NET技术 , ASP.NET
