c# - 我的代码充满了服务接口(interface)!

Question

大家好。我遇到了一个使用存储库和服务模型的奇怪设计模式。该应用程序由 ASP.NET MVC、WCF 和一些 Windows 服务组成。我的存储库正在使用 LINQ DataContext。随着我的应用程序的发展，我发现自己到处传递对 IWhateverService 服务的引用。例如，我有 IAccountService，它定义了 ChangePlan(Account account, Plan plan) 等方法。

现在，IAccountService 似乎是放置此方法的最佳位置，因为我们在这里为帐户提供服务。但是，ChangePlan 方法在实际更改计划之前需要知道几件事。它必须知道用户当前的使用情况、可用计划列表、用于计费的电子商务服务接口(interface)实例等。

我想让 ChangePlan 方法接受 IAccountService 接口(interface)中的所有必需服务。但这些其他服务的要求是一个实现问题，不应成为接口(interface)定义的一部分。

所以现在我发现自己为 AccountService 创建了一个巨大的构造函数，它采用了 IAccountRepository、IPlanService、IUsageService、IEcommerceService 和 IValidationDictionary 的实例。这感觉根本不对。

现在考虑这个场景。显然，IAccountService 包含一个通过 ID 检索用户帐户的简单方法:Account Get(int id) 有好几次我只需要调用此方法即可。因此，我开始创建我的 AccountService，它需要所有这些其他服务的实例(尤其是 IValidationDictionary，我不需要为此进行验证)。再一次，这感觉不对。我可以传递 null，但这只是因为我知道实现不会仅将它们用于此方法。

此外，为了避免在需要的任何地方实例化服务，我创建了一个名为 ServiceFactory 的静态类，它具有静态方法、CreateAccountService、CreatePlanService 等……我在应用程序周围调用这些方法。看起来不错，但我无法摆脱这种不合适的感觉。

我的断开连接在哪里？有人有什么建议吗？

谢谢。

安德鲁

Answer 1

您所描述的设计似乎与SOLID 非常一致。原则。许多较小的组件通常也被认为是好的设计。

SOLID 原则通常会接受您在实现 中描述的非规范化，并且宁愿专注于让此类组件的每个外部用例都有自己的接口(interface)。

我认为您遇到的主要问题是您花了太多时间考虑如何构造这些对象。你可能应该寻找一个依赖注入(inject)框架来处理这个问题，比如 Castle Windsor .然后，您只需构建完整状态的对象，而不必担心所有依赖项未用于每次调用。