Question

我以前从来没有问过这个一般的事情，我不确定这听起来好像我要求别人为我做我的工作。我是一名经验丰富的程序员，但我对那些在这类网站上讨论过的设计模式有点新鲜。

参数概要：

（1）有3个外部系统是有效的数据存储

System1 - REST System2 - WSDL System3 - COM Interop

（2）数据实体在2个系统中是有意义的，同时移入和移出（2个相应的系统）

（3）整个事情由同步管理器应用程序驱动。

实施概要：

（4）数据实体由生活在单独命名空间中的接口定义。

的IFoo 伊巴尔 IBaz

（5）工作由位于专用于系统的命名空间中的Utility类完成。

namespace MyCompany.Integrations.System1 {
 public static class Utility {
  public static List<IFoo> GetFoos(DateTime since) {...}
  public static void SaveBazes(List<IBaz> bases) {...}
 }
}

namespace MyCompany.Integrations.System2 {
 public static class Utility {
  public static void SaveFoos(List<IFoo> foos) {...}
  public static List<IBar> GetBars(DateTime since) {...}
 }
}

namespace MyCompany.Integrations.System3 {
 public static class Utility {
  public static void SaveFoos(List<IFoo> foos) {...}
  public static void SaveBars(DateTime since) {...}
 }
}

问题：现有的模式（如果有的话）与此类似，是否有任何我可以探索的领域可以帮助我学习如何改进我的架构？我知道Utility类不是OO。我还没有弄清楚如何布局类以简单的方式完成它。

补充：我想的更多，基于一个回应，我认为我不够具体。 我希望有更多经验的人告诉我如何应用一些OO模式并远离Utility类

Answer 1

10,000英尺回答：

您可能会发现Domain Driven Design和Clean Code很有用，因为它们为您提供了一组可以很好地协同工作的模式，以及一组用于评估何时应用模式的主体。 DDD资源：the book，free quick intro，excellent walkthrough。清洁代码资源：summary，SOLID principles。

具体答案：

您已经在使用我可能会在这里使用的Repository模式（您的实用程序类）。静态成员可以生成代码difficult to test，但其他方面不是问题。如果存储库变得过于复杂，请将低级API通信分解为Gateways。

由于实体分布在多个数据源中，因此请考虑明确地对其进行建模。例如：Person，HumanResourcesPerson，AccountingPerson。使用外部系统及其业务所有者理解的名称（例如，员工，资源）。出于某种原因，请参阅Single Responsibilty Principle和Ubiquitous Language。这些可能是完整Entities或仅Data Transfer Objects (DTOs)，具体取决于它们的复杂程度。

同步可能由协调存储库和实体的Application Service执行。

Answer 2

听起来你想要一个可以找到存储库的Finder模式，我的理解是否正确？如果是这样，那么关于Google中的Finder模式的研究应该会有一些信息。

我做了一个快速搜索并找到了这个：

http://martinfowler.com/articles/injection.html

对于将来自多个来源的数据与非标准apis集成的系统，使用了哪些典型模式？

2 个答案: