为什么 MVC 中的 Controller 类上的 TryUpdateModel 受到保护?

发布于 2024-11-02 03:29:38 字数 514 浏览 2 评论 0原文

原本这是一个如何执行任务的问题,但现在它变成了一个最佳实践的问题。

我正在使用 MVC(对它来说仍然是新的),并且我试图创建一个任何控制器都可以调用的方法,该方法将运行通用的功能。在该方法中,我需要运行控制器的 TryUpdateModel 方法。这就是我遇到障碍的地方 - 除非该方法位于控制器中,否则我无法执行此操作,因为 TryUpdateModel “由于其保护级别而无法访问” - 它被标记为“受保护”。如果我必须将此方法设为每个控制器的私有方法,那么它首先会破坏该方法的整个目的,并且我将复制粘贴大量代码。

所以我想知道,为什么这个方法受到保护?当然,我一定错过了一些显而易见的东西。 (请说明)

我最终创建了自己的继承自基本控制器类的控制器类。这个新类包含我需要在所有控制器中通用的方法。现在,我的控制器继承自我构建的这个新控制器类,而该新控制器类又继承自基本控制器类。它运作良好,似乎非常适合模型。

我的问题是——对于那些经常使用 MVC 的人来说,这个模型是不是一个坏主意?采取这样的中心类并创建自己的类并使用它通常是一个坏主意吗?

Originally this was going to be a question asking how to perform a task, but now it has turned into a question of best practice.

I am using MVC (still new to it) and I was trying to create a method that any controller can call that will run a common piece of functionality. Within the method, I needed to run the controller's TryUpdateModel method. This is where I was hitting a roadblock- I couldn't do this unless the method was IN the controller because TryUpdateModel is "inaccessible due to its protection level"- it is marked 'protected'. If I had to make this method private to each controller, it would defeat the whole purpose of having the method in the first place and I would be copy-pasting a lot of code.

So I was wondering, why is this method protected? Surely I must be missing something glaringly obvious. (And please do shed light)

What I ended up doing in creating my own controller class that inherits from the base controller class. This new class contains the method I needed to be common with all of my controllers. Now my controllers inherit from this new controller class I built that in turn inherits from the base controller class. It works well and seems to fit the model great.

My question is- for those that work with MVC regularly, is this model bad idea? Is it usually a bad idea to take such a central class and make your own and use it instead?

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(1

绻影浮沉 2024-11-09 03:29:38

这是受保护的,因为这些方法属于控制器代码内部。它们是控制器的扩展,专门用于控制器中。它们受到保护的事实意味着,按照设计,控制器中就存在这种情况。以 ASP.NET Web 表单为例,Page.IsPostback 旨在从页面本身内部调用。
控制器通常是模型绑定魔法适用的地方,因此 TryUpdateModel 也属于那里。您可能试图过于简单化,但我确实明白您为什么要这样做。能少抽象一层吗?在控制器中使用 tryupdatemodel 并在另一个“通用”方法中使用任何其他通用代码。
一般来说,控制器中的 mvc 代码保持相当简单,如果 !TryUpdateModel(model) 那么你只需返回并让 modelstate/validators 发挥它们的魔力。这是一种简单的方法,通常效果很好。您是否通过尝试实现其他方法来节省 2/3 行常见验证代码?

我不确定(因为 ModelState 等)使用另一个从控制器继承的类(其目的不是真正的控制器)是否在所有情况下都有效,所以要小心。 ModelState可能无法正确传递,等等。

This is protected because these methods belong inside controller code. They are extensions of the controller meant to be used specifically in the controller. The fact they are protected means that by design the intention was there for this to happen in a controller. Take asp.net web forms for example, Page.IsPostback is meant to be called from within the page itself.
The controller is generally where the model binding magic applies to, and hence TryUpdateModel belongs there as well. You may be trying to oversimplify a bit too much, but I do see why you would do this. Can you abstract one layer less? Use tryupdatemodel in your controller and any additional common code in another 'common' method.
Generally in mvc code in the controller stays fairly simply such that if !TryUpdateModel(model) then you simply return and let modelstate/validators do their magic. Its a simple method and generally works well. Are you saving 2/3 lines of common validation code by trying to implement this other method?

I'm not sure if (because of ModelState, etc) using another class that inherits from a controller, whose purpose isn't really a controller - will work in all cases - so beware with that. ModelState may not be passed around properly, etc.

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文