3

我有一个大型的“经理”类，我认为它做得太多，但我不确定如何将它划分为更多的逻辑单元。

一般来说，该类基本上由以下方法组成：

FooBarManager 类
{
  GetFooEntities();
  AddFooEntity(..);
  UpdateFooEntity(..);
  提交FooEntity(..);
  GetFooTypes();
  GetBarEntities();
}

Manager 类是我的业务逻辑的一部分，它在数据访问级别包含另一个“Manager”类的实例，其中包含所有实体的所有 CRUD 操作。

我有来自数据访问层的不同实体，因此在 Manager 类之外有一个转换器来将数据实体转换为业务实体。

管理器类的原因是我希望在进行单元测试时能够模拟每个“管理器”类。每个管理器类现在都超过 1000 个 loc，每个包含 40-50 个方法。我认为它们非常臃肿，并且发现将所有数据访问逻辑放在一个类中很尴尬。我应该做些什么不同的事情？

我将如何拆分它们，我应该使用任何特定的设计模式吗？

4

4 回答 4

1

你真的不应该把所有的数据访问放到一个类中，除非它是通用的。我首先将您的数据访问类拆分为每个对象或相关对象组的一个管理器，即 CompanyManager、CustomerManager 等。如果您需要通过一个“上帝类”访问管理器，您可以拥有每个可用管理器的实例在您真正的经理课程中。

于 2008-09-30T16:36:51.533 回答
1

你FooBarManager看起来很像一个上帝对象的反模式。

在像您这样的情况下，请考虑深入研究Martin Fowler的企业应用程序架构模式。乍一看，您似乎想要创建一个Data Mapper。但是考虑一下Active Record之类的替代方案，这可能足以满足您的需求。

还可以考虑为您的平台使用ORM 库/软件。在没有充分理由的情况下构建自己的工具只会让您面临这些工具或多或少已经解决的许多问题。

于 2008-09-30T16:45:58.077 回答
0 
       / FooManager
Manager                  (derive from Manager)
       \ BarManager

应该不言自明

于 2008-09-30T16:40:39.137 回答
0

我建议使用组合。想想经理正在做什么。按照单一职责划分它们。看起来大部分 FooBarManager 是 Foo 和 bar 实体的集合。因此，至少从 FooBarManager 中分离出集合逻辑

public class EntityCollection<T> : IList<T> 
 where T : BaseEntity
{ /* all management logic here */}
public class FooCollection : EntityCollection<foo> {}
public class BarCollection : EntityCollection<bar> {}
public class FooBarManager 
{ 
public FooCollection { /*...*/ } 
public BarCollection { /*...*/ } 
public FooBarManager() : this(new FooCollection(), new BarCollection()){}
public FooBarManager(FooCollection fc, BarCollection bc) { /*...*/ } 
}
于 2008-09-30T16:42:55.200 回答