ASP.Net MVC 架构 - 绕过控制器层？
背景
我正在构建一个 ASP.Net MVC 3 应用程序，该应用程序利用：
- 用于许多 UI 小部件/控件的 JQueryUI
- 用于 CRUD 操作的现有基于 SOA 的系统（使用 DDD 概念构建）。这包括针对读取操作进行优化的服务（请参阅 CQRS）。这些服务是 RESTful（托管在 IIS/Appfabric 中），因此可以通过 JavaScript 的简单 HTTP 请求进行访问。还可以通过引用服务二进制文件并从控制器访问（当然，通过层将控制器与服务解耦等）来轻松地直接使用服务。
问题
是否适合直接从 JavaScript 使用现有的 RESTful API 来执行读取操作，而不是调用随后进行服务调用的控制器方法？或者我们应该始终使用控制器方法进行任何类型的 CRUD 操作？
担忧
- 似乎违反了永远不应该绕过某个层的规则
- 。另一方面，如果我们总是使用控制器，那么感觉有点多余，因为我们本质上将服务包装在另一个 RESTful API 中使用 ASP.Net MVC 的时间。
当我开始考虑这个问题时，我的直觉是我们最终会为某些操作编写控制器方法，当我们在模型中拥有数据时，页面输出（视图）的操作可能是最简单的。然后还会有其他操作，例如可能提取员工列表以进行简单的查找，这不需要使用控制器方法，并且可以直接进入我们现有的 RESTful API。这感觉很混乱，一些开发人员会对何时使用 Controller 方法或直接使用现有的 RESTful API 感到困惑。
任何想法或建议将不胜感激。
谢谢。
Background
I'm working on building an ASP.Net MVC 3 application that utilizes:
- JQueryUI for many UI widgets/controls
- An existing SOA-based system for CRUD operations (built using DDD concepts). This includes a service optimized for read operations (see CQRS). The services are RESTful (hosted in IIS/Appfabric) and hence can be accessed via simple HTTP requests from javascript. The services can also easily be consumed directly by referencing the service binary and accessed from the Controller (or course, via layers to decouple the Controller from the service and so on).
Question
Is it ever appropriate to perform, for example, a read operation by using the existing RESTful API directly from javascript rather than invoking a Controller method that then makes the service call? Or should we always utilize Controller methods for any sort of CRUD operation?
Concerns
- Seems to break the rule that says you should never bypass a layer
- On the other hand, if we always utilize the Controller it then feels somewhat redundant in that we are wrapping the services essentially in another RESTful API this time using ASP.Net MVC.
My gut feel when I started looking at this was that we would end up writing Controller methods for some operations where perhaps manipulation of page output (the view) is easiest when we have the data in a model. Then there would be other operations, perhaps pulling a list of employees for a simple lookup for example, that would not need to utilize a Controller method and could go straight to our existing RESTful API. It feels messy and some developers will be confused as to when to use a Controller method or the existing RESTful API directly.
Any thoughts or suggestions would be appreciated.
Thanks.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
我想这是一个意见问题，但如果没有其他的话，我总是会通过控制器来保持一致性。正如您所说，如果您有时直接使用 API，但其他时候则通过控制器，那么您的开发人员可能会对如何访问数据感到困惑。
另一件值得考虑的事情是，通过使用控制器，您可以向最终用户隐藏 API，这可能是一件好事，因为恶意用户可以很容易地更改 Javascript 来执行您不期望的操作（尽管我' d 希望 API 有处理此问题的措施），但如果您始终通过控制器进行操作，则可以确保用户无法通过 API 直接操作数据。
即使安全性不是问题，正如我所说，我仍然每次都会选择控制器访问，只是为了保持一致。
I guess this is a matter of opinion, but I’d always go through a controller for consistency if nothing else. As you say, if you sometimes use the API directly, but other times go through a controller, then your devs are likely to get confused as to how they should access the data.
Another thing worth considering is that by using the controller, you’re hiding the API from the end user, which is probably a good thing as malicious users could quite easily change the Javascript to do things that you weren’t expecting (although I’d expect the API to have measures for dealing with this), but if you’re always going via a controller you can ensure that the user can’t directly manipulate the data via the API.
Even if security isn’t a problem, as I said, I’d still go with controller access every time just for the sake of being consistent.