使用 IoC 的项目中目录的推荐文件夹结构是什么答案

【问题标题】：What's the recommended folder structure of catalogs in project using IoC使用 IoC 的项目中目录的推荐文件夹结构是什么
【发布时间】：2020-01-02 20:56:24
【问题描述】：

我在 YT 上阅读了几篇关于 DI 和 IoC 的文章并观看了许多讲座/教程，但我没有在 VS 解决方案中找到任何推荐的目录布局。

我说的是项目（例如一个游戏），其中您有很少的类/接口、记录器、数据库提供程序、wcf 服务、wpf 表示层（实际上是不同的项目）...

是否有任何模式项目，显示我应该如何组织我的项目，所以接下来，有经验的程序员不会浪费时间弄清楚发生了什么？就像我们在谈论“自注释代码”一样，我在谈论“自注释项目结构”。

例如，我应该将所有接口都放入“接口”目录吗？或者我应该（在记录器的情况下）创建“记录器”目录并将接口、类、具有扩展方法的类（全部，专注于日志记录）放在那里。代码集中于 Board，在“Board”目录中。 “字段”等的单独目录。

现在的结构是这样的。我不确定那里的“业务”和记录器。我在不同的目录中有接口，然后是其他记录器类。我应该致电 Log4Net 提供商吗？或适配器？还是装饰师？它只是一个实现ILogger 接口的记录器类。这是屏幕：link

这是示例代码（目前还没有 IoC，但大家会注意到那里映射了 3 个接口。非常简单）：

public class Game
{
    public IBoard Board { get; set; }

    public Game(IBoard board)
    {
        Board = board;
    }
}

public interface IBoard {}

public class Board : IBoard
{
    public IField[,] Fields { get; set; }
    public Board(IField field, int boardWidth, int boardHeight)
    {
        Fields = new IField[boardHeight, boardWidth];
        Fields.Initialize();
    }
}

public interface IField {}

public class Field : IField {}

public interface ILogger
{
    void Log(LogEntry entry);
}

【问题讨论】：

严格基于意见 - 使用适合您/您的团队的布局。您使用的框架通常会建议一些布局（即 ASP.Net MVC 建议控制器/模型/视图文件夹），但没有真正的黄金标准（而且它可能也会因不同的 DI 容器而异）。
看看onion架构

标签： c# .net dependency-injection architecture inversion-of-control

【解决方案1】：

我通常做的是我有一个MyApplication.Core（类库）层，它包含所有应用程序接口，只有很少（阅读：无）第三方依赖项，例如ILogger、ICommand 或 IQuery<TResult>。

接下来我有一个MyApplication.Domain（类库）层，其中包含所有应用程序领域的特定知识——这是业务层。这是核心接口ICommand、IQuery<TResult> 的实现。然后，这些实现依赖于例如ILogger。从不具体的实现。

然后我有MyApplication.Infrastructure（类库），这是实现MyApplication.Core 的所有服务接口的地方，例如ILogger。在这里，您可以依赖第三方库，例如 Log4Net。

最后是表示层，在我的例子中通常是一个 MVC 应用程序，所以我将其命名为MyApplication.Web.Mvc。所有控制器都只依赖于接口。从不具体的实现。该层还负责使用Composition Root 将所有接口引导至具体实现。

TL;DR:

MyApplication.Core（应用程序接口层）
MyApplication.Domain（业务逻辑）
MyApplication.Infrastructure（应用程序接口层的实现）
MyApplication.Web.Mvc（表示和组合根层）

【讨论】：

所以，在Core 我只有接口，在Domain 我有游戏逻辑类（实现上述接口），所以游戏，棋盘，场。 Infrastructure 还是有点不清楚——它是只供第三方库“提供者”使用的地方吗？在哪里放置与数据库相关的代码 - 在 Infrastructure 中？
Domain 是业务逻辑，即您的实体所在的位置。是的，在我看来，第三方集成应该只在 Infrastructure 中完成，这也是您设置数据库连接的地方 - 可能通过来自 Core 抽象的简单 IRepository<TEntity>，因此您的实体可以通过通过硬依赖直接代替接口。
您可以查看github.com/janhartmann/nerve-framework，这是我制作的基础设施库。可以在github.com/janhartmann/nerve-framework-sample 查看示例应用程序 - 它可以为您提供有关如何构建应用程序的想法。
还有一件事：您如何看待将所有核心/域/基础架构放入单个项目 - 比如说“核心”。在里面，您可以将它们拆分为不同的文件夹（使用您建议的名称）。所以所有代码都将在单个 dll 中。将为演示创建另一个项目-在我的情况下是 WPF？ - 这是我的第一个想法。第二个想法和第一个一样，只是3rd-parties放了不同的dll（所以基础设施分开，Core+Domain在单个项目中（拆分在不同的文件夹中）。您如何看待这两个？
我不建议将所有内容都放在一个 DLL 中。当您希望切换依赖项时，这会使事情变得复杂（这就是最终的全部内容）。我可以接受您有一个Domain 层，其中在一个DLL 中同时包含Core 和Domain。但是Infrastructure应该是分开的。

【解决方案2】：

来自Microsoft's "Common web application architectures"。

应用核心项目

应用程序核心包含业务模型，其中包括实体、服务和接口。这些接口包括将使用基础设施执行的操作的抽象，例如数据访问、文件系统访问、网络调用等。有时在这一层定义的服务或接口需要与不依赖于 UI 的非实体类型一起工作或基础设施。这些可以定义为简单的数据传输对象 (DTO)。

基础设施项目

基础设施项目通常包括数据访问实现。在典型的 ASP.NET Core Web 应用程序中，这些实现包括实体框架 (EF) DbContext、已定义的任何 EF Core 迁移对象以及数据访问实现类。抽象数据访问实现代码的最常见方法是使用存储库设计模式。

除了数据访问实现之外，基础架构项目还应包含必须与基础架构关注点交互的服务实现。这些服务应该实现在 Application Core 中定义的接口，因此 Infrastructure 应该具有对 Application Core 项目的引用。

ASP.NET Core Web 应用项目

ASP.NET Core MVC 应用程序中的用户界面层是应用程序的入口点。该项目应引用 Application Core 项目，其类型应严格通过 Application Core 中定义的接口与基础设施交互。在 UI 层中不应允许直接实例化或静态调用基础设施层类型。

使用 ASP.NET Core 的 Clean Architecture 的起点 repo https://github.com/ardalis/CleanArchitecture

【讨论】：