3层架构问题

Question

现在，我已经开始研究三层架构了，但我还是有些疑惑。

通常我们将数据控件绑定到对象数据源，并调用业务对象的函数来执行选择、插入、更新或删除操作。我对这种方式没有任何问题。

但是，我的问题是，我有一个只包含2个文本框和1个按钮的登录部分，我创建了一个业务对象，其属性表示用户名和密码，然后我调用业务对象的函数，该函数反过来调用数据访问层的函数，以便在用户名和密码正确的情况下从数据库返回包含用户in的数据行……

所以我认为当你不使用data controls...because时，这是不正确的3层工作方式，我们不合理地调用函数和函数，而我们甚至可以在...so后面的代码中访问数据，请告诉我我的工作是否正确？或者有没有更好的方法来执行类似的操作。

Answer 1

当涉及到数据和业务逻辑的分离时，ASP.NET是奇怪的。MVC使它变得更容易，但您不能指定您是否正在使用它。我们解决这个问题的方法如下：

我们构建一个只负责与数据库交互的静态序列化类。它单独负责调用存储过程。它返回POCOs (普通旧式C#对象)的实例，序列化程序知道如何实例化这些实例，并用数据库中的数据填充这些实例。

现在，POCOs提供了将调用转发到序列化程序的外观方法。例如：

public static Employee Load(int id)

将在EmployeeSerializer类上调用Load方法。它不会做其他任何事情。但是它允许页面以一种自然的方式使用Employee对象。

可能不是正确的，但它比我们以前拥有的更好。类似地，您调用Employee.Save()，然后调用被转发到EmployeeSerializer。

这使所有存储过程调用都封装在一个类中。业务逻辑封装在Employee类中。而且pages可以只与员工一起工作。

请注意，业务对象可以与数据库对象位于不同的DLL中，但这往往会导致循环依赖关系的问题。将它们放在相同的DLL中，并将它们放在不同的命名空间中。但是要将它们与ASP.NET页面分开，将它们放在一个单独的DLL中。

Answer 2

这就是你说的那个懒惰的程序员。

三层是绝对的。你不能有一种-排序-3-层。这不是三层结构。

3层的存在是为了使代码在长期内更易维护，而不是在短期内减少开发时间。使用tiers luke。