如今，我已经开始研究3层架构，但我心里有些疑惑。
通常我们将数据控件绑定到objectdatasource并调用业务对象的函数来执行select，insert，update或delete操作。我没有这方面的任何问题。
但是，我的问题是我有一个只包含2个文本框和1个按钮的登录部分，我创建了一个业务对象，其属性代表用户名和密码，然后我调用业务对象的功能，该函数又称为数据访问层的功能如果用户名和密码正确，则从数据库返回包含userid的数据行....
所以我认为当你不使用数据控件时，这不是使用3层的正确方法...因为这里我们不合理地调用函数和函数，而我们甚至可以在后面的代码中访问数据...所以请告诉我，我是否正常工作？......或者有更好的方法来执行类似的操作。
答案 0 :(得分：1)
在分离数据和业务逻辑时，ASP.NET很奇怪。 MVC使其更容易，但您没有指定是否使用它。我们解决了以下问题：
我们构建一个静态序列化类，它独自负责与数据库交互。它本身负责调用存储过程。它返回POCO的实例（普通的旧C＃对象），序列化程序知道如何实例化和填充数据库中的数据。
现在，POCO提供了用于转发对序列化程序的调用的Facade方法。例如：
public static Employee Load(int id)
将在EmployeeSerializer类上调用Load方法。它不会做任何其他事情。但它允许页面以自然的方式使用Employee对象。
可能不对，但它比以前更好。同样，您调用Employee.Save（），并将调用转发给EmployeeSerializer。
这样可以将所有存储过程调用封装在一个类中。业务逻辑封装在Employee类中。页面可以与员工一起使用。
请注意，业务对象可以位于与数据库对象不同的DLL中，但这往往会导致循环依赖性问题。将它们保存在同一个DLL中，并将它们放在不同的命名空间中。但是将它们与ASP.NET页面分开，将它们放在一个单独的DLL 中。
答案 1 :(得分：1)
那是你说话的懒惰程序员。
三层是绝对的。你不能有类型三层。这不是3层。
从长远来看，3层是为了使代码更易于维护，而不是缩短在短时间内开发的时间。使用tiers luke。