asp.net mvc 在另一个控制器的构造函数中创建控制器的实例是否正确？
我有几个控制器，它们都将使用通用功能。所以我将该功能分离到一个单独的控制器中。
共享控制器需要一个特定于从哪个控制器使用它的参数，并且需要根据传递给它的 id 整数返回视图。
因此，一个想法是在每个将使用它的控制器的构造函数中创建 SharedController(int CallingControllerId) 的实例。然后，在每个控制器的操作方法中，调用共享控制器的操作方法，传递适当的 ID，并将视图从 SharedController 返回到调用控制器，这将返回要渲染的视图。
这听起来正确吗？控制器是否应该在 MVC 中创建其他控制器？
谢谢！
i have several controllers which will all be using common functionality. So i have separated that functionality into a separate controller.
the shared controller needs a parameter specific to which controller it is being used from, and needs to return views based on id ints passed to it.
So, one idea is to create an instance of SharedController(int callingControllerId) in the constructor of each of the controllers that will be using it. Then, within the action methods of each controller, call the action methods of the shared controller, passing appropriate ids, and returning views from SharedController to the calling controller, which would return the view to be rendered.
Does this sound right? Should controllers be creating other controllers in MVC?
Thanks!
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
绝对不是，尽管让你的控制器继承共享的基本控制器是很常见的。
就像 Greg Roberts 指出的那样，虽然 ControllerBase 很常见，但它并不总是存储共享功能的最佳位置。 MVC 有很多 扩展点并选择一个狭窄的地方来插入代码比将大量内容塞入基本控制器要好得多。
Absolutely not although having your controller inherit from a shared, base controller is pretty common.
Like Greg Roberts points out that although having a ControllerBase is common it is not always the best place to store shared functionality. MVC has a lot of extensibility points and picking a narrow place to wedge in your code is a lot better than smushing tons of things into a base controller.
我同意基本控制器非常常见，但我不确定这是否是您所描述内容的正确解决方案。
如果不知道确切共享的内容，则很难弄清楚，但是你的基本控制器的整个部分都知道从它继承的控制器的细节，有点味道。
这里有一些需要考虑的事情。
与软件中的任何内容一样，解决问题的方法有很多，因此最终要以对您和您的团队最有意义的方式进行。
I would agree that a base controller is pretty common, but I'm not sure it's the right solution for what you are describing.
Without knowing what is exactly shared it's a bit hard to figure out, but the whole bit of your base controller knowing specifics about the controllers that are inheriting from it smells a bit.
Here are a couple things to consider.
As with anything in software, there are tons of ways to solve the problem, so ultimately do it the way that makes the most sense to you and your team.
控制器是由 ASP.NET MVC 运行时构建的，您永远不应该在自己的代码中构建它们。听起来您实际上并不需要单独的控制器，您只需要在控制器中聚合并用作服务的另一个类。这是完全可以接受的。事实上，我什至想说，一般来说，控制器应该将他们的工作委托给其他“服务”类，并且它们本身不应该承担太多责任（特别是域逻辑）。
我不知道为什么这个服务类需要知道从哪个控制器调用它的详细信息，但也许您可以声明一个定义不同用例的枚举，并将其传递到其构造函数中。实际上让服务类了解不同的控制器对我来说是一种代码味道。
Controllers are constructed by the ASP.NET MVC runtime and you should never be constructing them in your own code. It sounds like you don't really need a separate controller, you just need another class that you aggregate in the controller, and use as a service. This is perfectly acceptable. In fact, I would go so far as to say that in general controller should be delegating their work to other "service" classes and shouldn't have much responsibility (especially domain logic) in and of themselves.
I don't know the details of why this service class needs to know what controller it is being called from, but perhaps you can just declare an enum that defines the different use cases, and pass that in in its constructor. Actually having the service class know about different controllers would be a code smell for me.