0

我正在编写一个 .net 网络表单应用程序。它有许多类，例如用户、预订等。目前我有许多管理器类，比如 bookingManager，它们管理这些类。例如，当创建一个新的预订时，您调用 bookingManager 中的 add 方法，并传递一个预订。然后检查预订是否有效，检查是否不冲突，如果不冲突，则将其添加到数据库中。对于其他类，我有类似的管理器，但是诸如用户管理器之类的管理器除了获取用户并添加到数据库之外并没有做更多的事情。所以我的问题是，这是做这类事情的最佳方式，还是有更适合这种情况的模式或方法？

4

4 回答 4

2

正如您所描述的那样，您已经在使用一种模式，即 3 层模式:)

这表明在应用程序中，您应该将代码分为 3 层（如名称所述）：

  1. 展示层：您编写代码以展示数据的位置（ASPx/winforms/等）

  2. 应用程序层：放置所有业务逻辑的位置（您对管理器类所做的事情）

  3. 数据层：您实际访问数据库的位置。

遵循这种模式可能很有用，例如，您有一个具有多个地址的客户端，客户端存储在一个表中，而地址存储在另一个表中。在您的表示层中，您只需调用应用程序层中的方法来保存客户端。在应用层，您将检查您的数据并调用数​​据层中的两种方法，一种用于保存客户端，另一种用于保存地址。

现在，如果您有多个地址的供应商，您可以在数据层中使用相同的方法来保存它们。

如果您有复杂的对象，这将很有用。但是，如果您的大多数对象都非常简单，我建议您考虑一下这种模式是否适合您。

http://en.wikipedia.org/wiki/Multitier_architecture

于 2008-12-22T12:07:09.727 回答
2

如果管理器就像 UI 和域类之间的控制器/演示者，我认为它应该是薄层。它应该包含几行代码。然后域服务或服务类应该负责休息工作。例如 ：

用户界面：

buttonClicked(Eventargs...)
{
   presenter.Save();
}

Presneter：

public void Save()
{
   bookingService.Save(view.Name,view.DateTime...)
}

服务 ：

public void Save(string name,DateTime dateTime...)
{
   //do operations or call repository/Dao classes to save
}

对于小型应用程序来说，它可能是矫枉过正，但对于大型应用程序，它会增加可维护性。您可以查看领域驱动设计书和领域服务类。

于 2008-12-22T12:10:25.760 回答
0

拥有经理课程并没有错，尤其是当他们管理系统的多个不同方面时，例如您提到的预订经理。在这种情况下，您可能不希望用户了解预订，或者预订了解用户 - 但这自然取决于您系统的具体情况。

  1. 管理器的好处是它提供了一个中央和逻辑的地方来存储可能依赖于多个组件的复杂逻辑。它还允许您使用数据类并增加这些类的凝聚力。

  2. 关于管理器的“不太好的”事情是您有另一个组件，它可能会合理地紧密耦合到系统中的其他组件。您需要平衡这方面的利弊，并选择对您的应用程序最有意义的架构。

于 2008-12-22T11:58:02.103 回答
0

我认为为此类类实现保存、删除和更新方法总是更好。用于此类事情的 Manager 类绝对是矫枉过正。例如，在您的 Booking 类中实现的那些方法可以进行相同的验证，并避免因向您的代码中添加太多类而引入的任何并发症。

于 2008-12-22T11:59:55.640 回答