什么时候应该在自己的控制器中提供功能？
我正在开发一个必须在不同页面上显示图表的网络应用程序。每个页面对应一个Controller，每个需要图表的Controller都有一个ChartService的接口。该服务请求第三方供应商提供图表。然后，它将用 JavaScript 封装在 HTML 中的图像作为字符串直接返回到输出流中。 ChartService 需要提供数据和一些其他参数，例如时间段和模板文件。
我应该将图表功能抽象到自己的控制器中吗？每种不同类型的图表都可以由 ChartController 上的不同操作方法提供服务。
但是，如果我从多个控制器提供某些页面，这会是一个问题吗？确定何时应为功能提供自己的控制器的准则是什么？
I am working on a web application that has to present charts on different pages. Each page corresponds to a Controller, and each Controller that needs a chart has an interface to a ChartService. The service requests a chart from a third party vendor. It then returns an image wrapped up in some HTML with JavaScript as a string directly into the output stream. The ChartService needs to be supplied with data and some other parameters like time period and template file.
Should I have the charting functionality abstracted into its own Controller? Each different type of chart could be served by a different Action Method on the ChartController.
But would it be a problem then that I'm serving some of my pages from multiple Controllers? What are the guidelines to determine when functionality should be given its own controller?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
听起来你根本不需要改变任何东西。您已将包装器内的第三方服务抽象出来，以便您的控制器不直接依赖于该特定服务。在这种情况下创建一个新的控制器相当于在你的包装器周围创建一个包装器。
当您想要向应用程序添加行为时，创建一个新控制器。
Sounds like you needn't change anything at all. You've abstracted away the third-party service inside of a wrapper so that your controllers don't depend directly on that specific service. Creating a new controller in this case would amount to creating a wrapper around your wrapper.
Create a new controller when you want to add behavior to the application.
戴夫，
我有一个抽象的基本控制器，你的主控制器继承自它。基本控制器将具有所有必需的功能，子控制器覆盖适当的部分。在不了解您困境的完整背景的情况下，这可能是也可能不是一种可行（或理想）的方法，但这是我目前在所有控制器中采用的方法。
[编辑] - 这种方法的优点在于，如果幸运的话，75% 的基本控制器功能将保留，只有 25% 的功能被覆盖和/或为该子控制器添加定制功能控制器。这将为您提供一个非常干净的范例，因为每个新图表类型都有自己的模型/控制器，并且具有可能相同的操作方法名称，从而使新图表类型的“进入”成本非常便宜。
吉姆
Dave,
I'd have an abstract basecontroller that your main controller inherited from. the base controller would have all the required functionality with the child controller overriding parts that were appropriate. without knowing the full context of your dilema, this may or may not be a feasible (or desirable) approach but it's one that i employ across all of my controllers at present.
[edit] - the beauty of this approach is that if you're lucky, 75% of the basecontroller functionality will remain with only 25% of the function being overriden and/or bespoke functionality added for that child controller. this would give you a very clean paradigm as each new chart type would have it's own model/controller with potentially identical action method names, thus making the cost of 'entry' for new chart types very inexpensive.
jim
IMO，如果您有一个带有 url 的“图表”部分
，那么图表控制器就有意义了。另外，如果您的图表控制器专门由各个页面的 ajax 查询调用，那么图表控制器仍然有意义。但是，如果您要拥有像
Then 这样的 url，您需要一个具有 List() 和yearlyStockChart() 操作的 ProductsController，以及一个具有details() 和 PerformanceChart() 操作的员工控制器，并且两个控制器都使用图表服务。
IMO, If you have a "charting" section with url's like
then a charting controller makes sense. Also, if for example your charting controller is called exclusively by ajax queries from various pages, then a chartingController still makes sense. But if you're going to have urls like
Then you'd want a ProductsController with List() and yearlyStockChart() actions, and an employeesController with details() and performanceChart() actions, with both controller making use of a chartingService.