如何在 Visual Studio 中实现 vNext Web API 2 层架构答案

【问题标题】：How to implement vNext Web API 2 layer architecture in Visual Studio如何在 Visual Studio 中实现 vNext Web API 2 层架构
【发布时间】：2015-07-22 07:02:52
【问题描述】：

我正在尝试使用 Microsoft vNext 技术 (Web API 2) 设计一个好的 Web API 架构。

我使用的是一个项目结构，类似这样：

Solution                                  
+                                         
+-+Web_API_Users (ASP.NET web api project)
|                                         
+-+BusinessContext1 (library project)     
| |                                       
| +--+BusinessService1 (public class)     
| |                                       
| +--+BusinessObject1 (inner class)       
| |                                       
| +--+BusinessObject2 (inner class)       
|                                         
+-+DataContext (library project)          
  |                                       
  +--+DataAccess1 (public class)

我正在考虑通过创建不同的项目在 Web api 层分离关注点（主要是分配不同的团队并考虑简化代码长度和可读性），如下所示：

Solution                                     
+                                            
+-+Web_API_Users (ASP.NET web api project)   
|                                            
+-+Web_API_Accounts (ASP.NET web api project)
|                                            
+-+Web_API_Clients (ASP.NET web api project) 
|                                            
+-+BusinessContext1 (library project)        
| |                                          
| +--+BusinessService1 (public class)        
| |                                          
| +--+BusinessObject1 (inner class)          
| |                                          
| +--+BusinessObject2 (inner class)          
|                                            
+-+DataContext (library project)             
  |                                          
  +--+DataAccess1 (public class)

但现在我又想到这可能是个坏主意。主要是因为我认为有几个带有 web api 引用的项目可能会在路由中发生冲突，但我不清楚这是不是真的。

所有示例和文档都来自一个简单的视图，包含一些路由和简单的 POCO 交互。

我正在寻求有关对此做出良好架构决策的建议。正如你可以想象的那样，我正计划发展这么大，所以我想从一开始就做出最好的决定。谢谢！

【问题讨论】：

标签： c# .net architecture asp.net-web-api

【解决方案1】：

您当然可以将 Web API 控制器放在单独的子程序集中，然后通过实现 IAssembliesResolver 注册这些程序集。另见 http://www.strathweb.com/2013/08/customizing-controller-discovery-in-asp-net-web-api/ http://www.strathweb.com/2012/06/using-controllers-from-an-external-assembly-in-asp-net-web-api/

【讨论】：

我担心的不是controller端，而是WebApiConfig.cs文件，所有路由都在这里注册。所有路线都需要在同一个文件中吗？既然您谈到了不同的程序集，那么从性能角度来看，将它们分开还是一个整体更好？
我还发现我只是不了解 Web API 架构。你的回答得到了几个很好的讲座。我最终决定只使用一个项目并根据需要实现尽可能多的控制器，直到我需要分离和实现单独的程序集。