我应该如何将庞大而臃肿的课堂分为更小的课堂？

我有一个很大的'经理'类，我认为这是太多了，但我不确定如何将它分成更多的逻辑单位。我应该如何将庞大而臃肿的课堂分为更小的课堂？

一般来说类基本由以下方法：

 
class FooBarManager 
{ 
    GetFooEntities(); 
    AddFooEntity(..); 
    UpdateFooEntity(..); 
    SubmitFooEntity(..); 
    GetFooTypes(); 
    GetBarEntities(); 
}

经理类是我的业务逻辑的一部分，constains包含所有CRUD的数据访问级别的其他“经理人”类的一个实例所有实体的操作。

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

经理类的原因是我希望能够在单元测试时嘲笑每个“经理”类。每个管理员类现在都超过1000个loc，每个管理员类包含40-50个方法。我认为它们很臃肿，并且觉得把所有的数据访问逻辑放到一个类中是很尴尬的。我应该做什么不同？

我将如何去分裂他们，是否有任何特定的设计模式，我应该使用？

来源

2008-09-30 Xerx

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

来源

2008-09-30 16:36:51

好的听起来很符合逻辑，但是如何在业务层的xManager中去处理需要获取客户所有订单的信息呢？你是否可以引用CustomerManager和OrderManager，以及何时获得客户电话获取该客户的订单？看起来像很多经理？ – Xerx 2008-09-30 16:54:37

鉴于你现在有什么，这就是我将如何做到这一点。考虑哪个实体负责操作 - 你不会要求真正的客户给你一个他们的订单清单，你会要求你的订单系统给你一个客户订单清单。 – 2008-09-30 18:59:21

 /FooManager 
Manager     (derive from Manager) 
     \ BarManager

应该是自我解释

来源

2008-09-30 16:40:39 daddz

我建议使用成分。考虑经理正在做的功能。按照单一职责划分它们。看来大部分FooBarManager是Foo和条形实体的集合。所以，至少，从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-30 16:42:55 Will

你FooBarManager打出来的信息收集逻辑看起来很像一个God Object反面模式。

在像你这样的情况下，考虑钻研由Martin Fowler提供的Patterns of Enterprise Application Architecture。乍一看，它看起来像你想创建一个Data Mapper。但考虑像Active Record这样的替代方案，这可能足以满足您的需求。

还可以考虑在您的平台上使用ORM library/software。没有一个好理由建立你自己的世界只会让你面对许多已经或多或少被这些工具解决的问题。

来源

2008-09-30 16:45:58 Mac

我应该如何将庞大而臃肿的课堂分为更小的课堂？

回答

相关问题