洋葱架构中的抽象工厂模式答案

【问题标题】：Abstract Factory Pattern in Onion Architecture洋葱架构中的抽象工厂模式
【发布时间】：2015-11-13 01:28:54
【问题描述】：

早上好，我的问题是关于 Visual Studio 项目/目录结构的。我正在创建一个简单的项目，我想在那里采用 Onion Architecture。我有几个层（项目）：MyProject.Domain（带有枚举、实体、接口）、MyProject.API、MyProject.Infrastructure.DependecyResolution , MyProject.Client.WPF

我想使用抽象工厂模式。我有 factory 类，以及少数 product 类。

我的“产品” 接口在域-> 接口中，我的“产品” 实现在域-> 实体中。在我的 Visual Studio 解决方案中，我应该将工厂的接口和实现（将创建那些产品）放在哪里？

我的问题是：Factory interface 或 Factory 具体实现 是 Onion Arch 中 Domain 的一部分吗？或者我应该为工厂创建另一个项目？这个问题更多是关于良好的编程实践，保持 Visual Studio 解决方案干净整洁。

【问题讨论】：

相关问题：stackoverflow.com/q/1894102/1168342
您尝试使用此模式解决的问题是什么？专注于您需要解决的问题，而不是特定的模式，您可能会发现其他模式更适合。无论如何，正如其他人所说，您可以通过多种方式实现此模式。这种架构的一个关键优势是它的灵活性，因此您可以在以后发现需要时改变您的设计。
我的“问题”，虽然我称之为“目标”，但我将拥有一个简单的应用程序——一种游戏。而现在，我将制作一些类似的游戏。所以我想创建一个尽可能灵活并随时可以扩展的项目。

标签： c# visual-studio design-patterns factory abstract-factory

【解决方案1】：

没有一个正确的答案。也许您可以创建一个文件夹“核心”，将所有核心代码放在其中。在其中创建一个“interfaces”文件夹并没有什么问题，而且通常会看到一个名为“entities”的文件夹包含各种数据类。

【讨论】：

【解决方案2】：

我的问题是：工厂接口或工厂具体实现是 Onion Arch 中域的一部分。？

我不是 Onion Architecture 哲学方面的专家，但有一些论据将工厂与产品放在同一个包中：

工厂可见，而产品包装可见（这意味着外部客户将无法直接访问产品；他们必须经过工厂），
通过 Robert Martin 的 REP（Reuse Release Equivalency Principle）的包内聚说“重用的颗粒就是发布的颗粒”。如果您不将工厂与他们的产品捆绑在一起，那么包装将无法轻松重复使用。

【讨论】：

【解决方案3】：

我的想法是在软件核心的领域项目中创建 Ifactories 文件夹，但在上层实现它们

在核心中引入接口的好处是上层可以使用它们

在上层引入实现的好处是封装实现

【讨论】：