多层MVC应用中WebApi层的部署位置咨询（.NET 4.7.2转Core场景）

先明确你两个方案的核心问题 #

• 方案一（MVC控制器调用WebApi）：属于同进程内的冗余HTTP调用，平白增加序列化/反序列化开销，完全没必要。WebApi的核心作用是给前端（比如未来的React）提供接口，MVC控制器直接调用服务层才是高效的同进程调用方式。
• 方案二（服务层调用WebApi+移除仓储层）：完全搞反了依赖关系。服务层是业务逻辑的核心，本该依赖仓储层做数据访问；WebApi只是服务层能力的对外暴露载体，让服务层依赖WebApi会把业务逻辑和HTTP协议强耦合，彻底违背分层设计的初衷。

最优过渡架构（兼容现有业务+适配未来迁移） #

保持现有分层的核心逻辑，新增WebApi层作为服务层的对外接口层，架构流程如下：

• 现有MVC控制器：继续直接调用服务层，正常渲染MVC视图，兼容现有业务流程
• 新增WebApi控制器：依赖服务层，提供REST风格接口，供当前的SammyJS/Knockout SPA调用，未来无缝对接React
• 服务层：保留原有业务逻辑，继续依赖仓储层处理SQL数据交互
• 仓储层：维持数据访问职责，后续可迁移为基于EF Core的实现以适配.NET Core

这个架构的优势：

• 不对现有业务做破坏性修改，迁移风险极低
• WebApi层只负责HTTP相关逻辑（参数校验、响应格式化、身份认证等），不掺杂业务逻辑，职责清晰
• 为React SPA的迁移铺路，前端可以逐步切换为调用WebApi，和现有MVC视图并行运行，实现平滑过渡

最终架构（完全迁移到React+.NET Core后） #

当React完全替代原有SPA后，可以逐步弱化甚至移除MVC控制器，架构简化为：
React前端 → WebApi控制器 → 服务层 → 仓储层 → SQL Server

额外注意事项 #

• 迁移到.NET Core时，将服务层、仓储层、WebApi层都重构为.NET Core项目，严格遵循WebApi依赖服务层，服务层依赖仓储层的依赖方向，禁止反向依赖
• 采用.NET Core内置的依赖注入（DI）管理各层实例，提升代码的可测试性和扩展性
• 统一异常、日志处理：WebApi层添加全局过滤器处理HTTP层面的异常，服务层专注抛出业务异常，仓储层处理数据访问异常，职责分离更清晰

内容的提问来源于stack exchange，提问作者QubeSimon