不带System.Web.Http的ASP.NET Web API控制器（可插拔、解耦体系结构）

我正在使用ASP.NETWebAPI创建一个可插入的项目框架。我有很多胆量，但我对体系结构的一个部分有一个问题，我不完全确定如何解耦

作为一个简化的例子，我有以下几点：

• 服务/表示层（简单的WebAPI托管项目，内部很少，基本上只是一个shell，在IIS或自托管中处理托管）
• 域层，具有核心，域层的项目块
• 服务（N个服务，每个服务都引用域层：想想微服务）。目前，这些服务中的每一个都有对ASP.NET Web API 2.1的引用

现在，所有服务都引用域层，因为它有接口、助手等。但是，域层也引用ASP.NET Web API 2.1等内容。我的想法是在域中有一个基本的“BaseController”，每个服务的控制器都可以从中继承，反过来，所有服务都必须继承连接的东西，如Get（）、Post（），等等。问题是我不希望这些服务中的每一个都必须引用ASP.NET Web API 2.1和其他依赖项。我希望他们能够通过抽象使用它们，而不直接引用它们。换句话说，我想要更松散的耦合，并且希望服务能够独立于System.Web.Http独立地运行。随着项目的发展，它将帮助我加强单元测试和坚实的原则

也许我采取了错误的方法，但也许不是。我的主要目标是使用ASP.NET Web API创建一个可插拔的微服务框架，每个微服务作为一个独立的组件存在。因此，如果有其他推荐的方法，我洗耳恭听

希望这是有道理的。有什么建议吗？值得一提的是，我非常熟悉设计模式和坚实原则的概念；只是不知道如何在保持控制器本机提供的一些自动请求处理的同时将这一切串在一起

---

谢谢

您的意图很好，但实施的力度不大。您实际上称之为应用程序服务，它们是使用域实现应用程序用例的服务。当你说你不想耦合到System.Web.Http等时，我想你是想说你不想你的应用程序（尤其是域）耦合到WebApi框架

我想你误解了脱钩的含义。这并不是说一个程序集不依赖另一个程序集，而是说不将对象/层耦合到其他对象/层的实现细节。这就是为什么域不应该知道控制器、WebApi、Mvc等，它们不是域的一部分，它们是UI或公共API的一部分

只有API层（名称巧合）应该知道控制器和您正在使用的任何框架（顺便说一下WebApi），其他任何东西都只知道它们的关注点。因此API使用->应用层->域

拥有自主组件是可以的，但您确实不希望只有一个部件来处理所有事情。保持事物清洁，并有类似于：

• MyFeature.ApplicationServices
• MyFeature.Domain
• MyFeature.Persistence
• 甚至MyFeature.ui小部件（Web/Wpf等）

这只是一个建议，重要的是将关注点分开

这里有一些代码

public class MyAppService 
{
       public void DoSmth(InputData data){}
}

public class MyApiController
{
     public MyApiController(MyAppService svc) { }

     public void Post(SomeModel model)
     {
        var svcInput=model.ToServiceInput();
        _svc.DoSmth(svcInput);
     }

}

---

您的应用程序服务从控制器获取一个输入模型，并使用该模型完成其工作。该服务从来不知道webApi或任何东西，只知道输入模型。而且事情是解耦的，易于测试。

您的意图很好，但实现并不多。您实际上称之为应用程序服务，它们是使用域实现应用程序用例的服务。当你说你不想耦合到System.Web.Http等时，我想你是想说你不想你的应用程序（尤其是域）耦合到WebApi框架

我想你误解了脱钩的含义。这并不是说一个程序集不依赖另一个程序集，而是说不将对象/层耦合到其他对象/层的实现细节。这就是为什么域不应该知道控制器、WebApi、Mvc等，它们不是域的一部分，它们是UI或公共API的一部分

只有API层（名称巧合）应该知道控制器和您正在使用的任何框架（顺便说一下WebApi），其他任何东西都只知道它们的关注点。因此API使用->应用层->域

拥有自主组件是可以的，但您确实不希望只有一个部件来处理所有事情。保持事物清洁，并有类似于：

• MyFeature.ApplicationServices
• MyFeature.Domain
• MyFeature.Persistence
• 甚至MyFeature.ui小部件（Web/Wpf等）

这只是一个建议，重要的是将关注点分开

这里有一些代码

public class MyAppService 
{
       public void DoSmth(InputData data){}
}

public class MyApiController
{
     public MyApiController(MyAppService svc) { }

     public void Post(SomeModel model)
     {
        var svcInput=model.ToServiceInput();
        _svc.DoSmth(svcInput);
     }

}

---

您的应用程序服务从控制器获取一个输入模型，并使用该模型完成其工作。该服务从来不知道webApi或任何东西，只知道输入模型。而且事情是解耦的，易于测试。

这绝对是有道理的。谢谢你非常详细的回答。我非常熟悉（从学术角度）您所描述的方法，也听说它被称为编排层（AppServices），如果我没有弄错的话。我完全可以看出这是如何更好地工作的。这种方法的主要原因是为开发人员提供了在尽可能少的行中创建“服务”的能力，因此继承了基本ApiController。我可能只是把事情复杂化了。“脱钩”一词的优点；我用的是一种通用的、令人困惑的方式所有这些都说了，你能嫉妒吗