经理班?

时间:2008-12-22 11:50:03

标签: .net design-patterns webforms methodology

我正在编写一个.net webforms应用程序。它有许多类,例如用户,预订等。 目前我有一些管理这些类的经理类,比如bookingManager。例如,在创建新预订时,您可以在bookingManager中调用add方法,然后通过预订。然后它检查预订是否有效,检查它是否有冲突,如果没有,则将其添加到数据库。 我有其他类的类似管理器,但是诸如用户管理器之类的管理器做的不仅仅是取用户并添加到数据库。 所以我的问题是,这是做这种事情的最佳方式,还是有更适合这种情况的模式或方法?

4 个答案:

答案 0 :(得分:2)

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

这说明在应用程序中,您应该将代码分为3层(如名称所示):

  1. 演示层:您编写代码以显示数据的位置(ASPx / winforms / etc)

  2. 应用程序层:您放置所有业务逻辑的位置(您使用Manager类执行的操作)

  3. 数据层:您对数据库的实际访问权限。

  4. 如果客户端具有多个地址,则客户端存储在一个表中,而地址存储在另一个表中,则遵循此模式非常有用。在表示层中,您只需调用应用程序层中的方法来保存客户端。在应用程序层中,您将检查数据并在数据层中调用两种方法,一种用于保存客户端,以保存地址。

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

    如果您有复杂的对象,这将非常有用。但是,如果你的大部分物品都很简单,我建议你考虑一下这个模式是否合适。

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

答案 1 :(得分:2)

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

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
}

对于小型应用程序来说可能有点过分,但对于大型应用程序来说,它可以增加维护。您可以查看域驱动设计书和域服务类。

答案 2 :(得分:0)

拥有经理课程没有任何问题,特别是当他们管理系统的几个不同方面时,例如您提到的预订经理。在这种情况下,您可能不希望用户了解预订或预订以了解用户 - 但这自然取决于您系统的具体情况。

  1. 管理者的好处是,它提供了一个中心和逻辑的位置来存储可能复杂的逻辑,这取决于多个组件。它还允许您使用数据类,并增加这些类的内聚力。

  2. 管理者的“不太好”的事情是你有另一个组件可能会合理地紧密耦合到系统中的其他组件。您需要平衡这方面的优点和缺点,并选择最适合您应用的架构。

答案 3 :(得分:0)

我认为为这些类实现Save,Delete和Update方法总是更好。对于这类事情的经理类肯定是矫枉过正。在您的,例如,Booking类中实现的那些方法可以进行相同的验证,并避免通过在代码中添加太多类而引入的任何复杂性。