使用IoC的项目中，目录的推荐文件结构是什么？

Question

使用IoC的项目中，目录的推荐文件结构是什么？

c#.netdependency-injectionarchitectureinversion-of-control

9

我已经阅读了很多关于DI和IoC的文章并在YT上看了许多讲座/教程，但我没有发现任何VS解决方案目录的推荐布局。

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

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

例如，我应该将所有接口放入“Interfaces”目录中吗？或者我应该（在记录器的情况下）创建“Logger”目录，并将其放置在接口、类、具有扩展方法的类中（全部，专注于记录）。在“Board”目录中专注于板块的代码。单独的目录用于“Field”等等..

现在的结构看起来像这样。我对“Business”和“Logger”不太确定。我在不同的目录中有接口和其他日志记录器类。我应该调用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);
}

- Abigail Baar

严格来说，这是基于意见的问题——使用适合您/您团队的布局。通常，您使用的框架会建议一些布局（例如ASP.Net MVC建议控制器/模型/视图文件夹），但实际上并没有真正的黄金标准（在不同的DI容器之间也可能有所不同）。 - Alexei Levenkov

2

看一下洋葱架构。 - qujck

2个回答

11

来源于Microsoft的“常见Web应用程序架构”

应用程序核心项目

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

基础设施项目

基础设施项目通常包括数据访问实现。在典型的ASP.NET Core Web应用程序中，这些实现包括Entity Framework（EF）DbContext、已定义的任何EF Core Migration对象和数据访问实现类。抽象数据访问实现代码的最常见方法是通过使用存储库设计模式。

除了数据访问实现之外，基础设施项目还应包含必须与基础设施问题交互的服务实现。这些服务应实现在应用程序核心中定义的接口，因此基础设施应具有对应用程序核心项目的引用。

ASP.NET Core Web应用程序项目

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

使用ASP.NET Core的清洁架构起始点repo https://github.com/ardalis/CleanArchitecture

- Joel Wiklund

网页内容由stack overflow 提供, 点击上面的

可以查看英文原文，
原文链接

- janhartmann · Accepted Answer

我通常的做法是，我有一个名为MyApplication.Core（类库）的层，其中包含所有应用程序接口，并且没有第三方依赖项，例如ILogger，ICommand或IQuery<TResult>。

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

然后我有一个名为MyApplication.Infrastructure（类库）的层，该层实现了来自MyApplication.Core的所有服务接口，例如ILogger。在此，您可以依赖第三方库，如Log4Net。

最后，我有表示层，这在我的情况下通常是MVC应用程序，因此我将其命名为MyApplication.Web.Mvc。所有控制器只依赖于接口。不要使用具体实现。该层还负责使用组合根将所有接口引导到具体实现。

TL;DR:

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