C# Clean Architecture - 创建抽象的最佳方法

Question

我收到了关于这个话题的不同意见，所以我决定来这里问这个问题。 我有一个在 .NET Framework 上编写的相对较旧的代码库，我必须将其迁移到具有 Clean Architecture 的 .NET 6。

在应用程序层中，我有一个大而困惑的帮助程序类，它使用大量服务和其他具有当场实例化逻辑的类。

CacheService cacheService = new CacheService()

StepExecutor stepExecutor = new StepExecutor();

CacheInvalidator cacheInvalidator = new CacheInvalidator();

等等...

这些类的实现现在应该移至基础设施层。

因此，对于服务，我在应用程序层中创建了合约，并将实现移至基础设施层，并通过构造函数注入(inject)它们巨大的助手类。一切都好。

我关心的是其他类型的类，一些例子:管理器、帮助器、失效器、执行器、处理程序类。 (CacheInvalidator、StepExecutor、WorkflowManager、EventHandler)

为这些类添加抽象层的最佳方法是什么？还将它们作为服务并通过构造函数注入(inject)它们？我应该使用工厂吗？ wrapper ？我非常感谢关于这个主题的任何见解。任何意见，任何文件。 我个人认为这个类应该完全重写和拆分。

如果这是一个非常愚蠢的问题，我真的很抱歉，我没有找到与我类似的场景，我发现的大多数东西都只在具有 2 个服务的小项目上，其中抽象层是添加完毕，仅此而已。这是我第一次做这样的事情。

提前致谢，我希望这对将来的人有所帮助!

Answer 1

对于这些其他类(管理器、助手、处理程序等)，您必须做出的第一个决定是:该代码应该放在哪一层？一切都与业务逻辑有关吗？然后它应该保留在应用程序层，您可以直接使用它们，也可以通过接口(interface)和工厂使用它们。

这些类应该被视为“基础设施”吗？您想要远离业务逻辑的东西？然后按照您已经描述的方法进行操作(应用程序层的接口(interface)，基础设施层的实现)。

可能 - 在遗留代码库中并非不可能 - 这些类往往位于“中间”:某些方面可以被视为业务逻辑，其他方面可以被视为基础设施。那么你应该努力分类，然后按照上面的描述继续。