现在，我已经开始在3层架构工作，但我已经在我的心中有一个疑团。3层架构问题
一般来说，我们的数据控件绑定到一个ObjectDataSource控件，并调用业务对象的功能进行选择，插入，更新或删除操作。这种方式我没有任何问题。
但是，我的问题是，我有一个登录部分，只包含2个文本框和1个按钮，我创建了一个业务对象，其属性代表用户名和密码，然后我调用业务对象的功能，该功能依次称为数据访问层函数返回从数据库中包含一个用户ID数据行，如果用户名和密码是正确的....
，所以我认为这是不与3层的工作，当你不使用数据控件工作的正确方法......因为在这里我们无理调用功能和功能的同时，我们甚至可以在后面的代码中访问数据......所以请告诉我，我是否正确或不工作？......还是有进行同样的操作中没有更好的办法。
ASP.NET是奇数，当涉及到数据和业务逻辑的分离。 MVC使它更容易，但你不指定是否使用它。我们解决这个问题如下：
我们构建了一个静态的序列化类，它负责与数据库交互。它本身负责调用存储过程。它返回序列化器知道如何实例化和用数据库中的数据填充的POCO实例（普通的旧C＃对象）。
现在，波苏斯提供转发到串行电话门面方法。例如：
public static Employee Load(int id)
将调用EmployeeSerializer类的Load方法。它不会做别的。但它可以让页面以自然的方式与Employee对象一起工作。
可能不适合，但它比我们以前更好。同样，您调用Employee.Save（），并将调用转发给EmployeeSerializer。
这使所有封装在一个类中调用存储过程。业务逻辑封装在Employee类中。并且页面可以与Employees一起工作。
注意，业务对象可以住在从数据库对象的一个单独的DLL，但是这往往导致循环依赖。将它们保存在同一个DLL中，并将它们放在不同的名称空间中。但是通过将它们放在一个单独的DLL 中，可以将它们与ASP.NET页面分开。
那就是懒惰的程序员在你说话。
三层是绝对的。你不能有三分法。这不是三层。
3层有使代码从长远来看更容易维护，不能减少时间短千卡发展。使用层级卢克。