ASP.Net MVC架构 - 旁路控制器层？

Question

背景

我正在开发一个利用以下内容的ASP.Net MVC 3应用程序：

• 许多UI小部件/控件的JQueryUI
• 用于CRUD操作的现有基于SOA的系统（使用DDD概念构建）。这包括针对读取操作优化的服务（请参阅CQRS）。这些服务是RESTful（托管在IIS / Appfabric中），因此可以通过来自javascript的简单HTTP请求进行访问。通过引用服务二进制文件并从Controller访问（或者通过层将Controller与服务分离等等），也可以直接使用这些服务。

问题

是否适合通过直接从javascript使用现有RESTful API执行读取操作，而不是调用然后进行服务调用的Controller方法？或者我们是否应该始终将Controller方法用于任何类型的CRUD操作？

关注

• 似乎违反了规定你永远不应绕过一层的规则
• 另一方面，如果我们总是使用Controller，那么感觉有点多余，因为我们这次使用ASP.Net MVC将服务基本上包装在另一个RESTful API中。

当我开始关注这个问题时，我的直觉是我们最终会为某些操作编写Controller方法，当我们在模型中获得数据时，可能最简单的操作页面输出（视图）。然后会有其他操作，例如，可能会为简单查找提取员工列表，这些操作不需要使用Controller方法，而是可以直接使用我们现有的RESTful API。它感觉很乱，一些开发人员会对何时直接使用Controller方法或现有RESTful API感到困惑。

任何想法或建议都将不胜感激。

感谢。

Answer 1

我想这是一个意见问题，但我总是会通过一个控制器来保持一致性。如你所说，如果你有时直接使用API​​，但有时候通过控制器，那么你的开发人员可能会对如何访问数据感到困惑。

另一件值得考虑的事情是，通过使用控制器，您将隐藏最终用户的API，这可能是件好事，因为恶意用户可以非常轻松地更改Javascript以执行您不期望的事情（虽然我希望API有处理这个的措施，但如果你总是通过控制器，你可以确保用户不能通过API直接操作数据。

即使安全性不是问题，正如我所说，每次只是为了保持一致，我仍然会使用控制器访问。