CustomViewData 的最佳方式?
将自定义属性添加到侧宽 ViewDataDictionary 的最实用方法是什么?
让我们假设一个简单的情况:
public ActionResult Index()
{
// ViewData["Title"] = "Home";
ViewData.Title = "Home";
return View();
}
首先想到的是自定义类并在应用程序基础控制器中使用“new”:
public class CustomDataDictionary : ViewDataDictionary
{
public string Title { get; set; }
}
public class ApplicationController : Controller
{
public new CustomDataDictionary ViewData { get; set;}
}
我假设您还必须创建一个具有相同属性的相应 CustomViewPage 才能使用自定义也在视图中查看数据字典。
我想到的第二件事是创建一个 ViewDataDictionaryExtensions 类。
第三,使用“视图模型”。 我对视图模型的不满是,总是创建一个视图模型并将其传递到视图中,这看起来就像在控制器代码中一遍又一遍地重复自己,至少与前两个选项相比是这样。
真正的目标是每个应用程序可能在 ViewData 中具有一组对该应用程序目的有意义的核心属性。 我倾向于回避依赖字典键,如果其他开发人员能够依靠真实的属性来知道要设置哪些数据,那就太好了。 另外,按键很容易拼写错误。
所有三种方法都可以完成工作。 其他人做了什么?
What's the most practical way to add custom properties to a side wide ViewDataDictionary?
Let's assume a simple case:
public ActionResult Index()
{
// ViewData["Title"] = "Home";
ViewData.Title = "Home";
return View();
}
The first thing that comes to mind is a custom class and using "new" in a application base controller:
public class CustomDataDictionary : ViewDataDictionary
{
public string Title { get; set; }
}
public class ApplicationController : Controller
{
public new CustomDataDictionary ViewData { get; set;}
}
I'm assuming you would also have to also make a corresponding CustomViewPage with the same property to use the custom view data dictionary in the views as well.
The second thing that comes to mind is to create a ViewDataDictionaryExtensions class.
Thirdly, use a "View Model". My beef with View Models are that always creating one and passing it into View seems like repeating yourself over and over in controller code, at least compared to the previous two options.
The real goal is that each application might have a core set of properties in the ViewData that make sense for that apps purpose. I tend to shy away from relying on dictionary keys, and it would be nice to have real properties for other developers to rely one to know what data to set. Plus, keys can easily be misspelled.
All three methods get the job done. What have others done?
如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
发布评论
评论(3)
关于名称拼写错误的问题 - 这就是常量的用途。
为了正确输入
ViewData
,您需要继承等; 因此,当您完成此操作时,我想知道您是否不能轻松地将一些常用代码添加到设置密钥的控制器中。至少对我来说,使用密钥似乎是最简单的答案 - 这也适用于最广泛的情况(即某些代码只知道基本的
IDictionary
)。您可能还对此相关问题感兴趣。
Re the problem with names getting misspelt - that is what constants are for.
For
ViewData
to be typed appropriately, you'd need to inherit etc; so by the time you've done that, I wonder if you couldn't just as easily add some common code into the controller that sets a key.Using a key seems, to me at least, the least complex answer - that also works in the widest number of cases (i.e. where certain code only knows about a basic
IDictionary<string,object>
).You may also be interested in this related question.
所有这些听起来都可行。 我认为您选择哪一个取决于您的要求/需求。 (确实是独特且内容丰富的答案,嗯?)
您的问题是“其他人做了什么?” 尽管。 因此,如果您进行民意调查,我最近对较小的应用程序使用了常量方法。 我还没有完成企业 MVC 应用程序,但我想我可能会创建一个继承 Controller 并定义这些额外属性的基类。 如果我想将这些一致地传递给视图,我同样会为我的模型建立一个基类。 然而,这必须谨慎使用——即使你正式输入它们,它们的行为仍然很像全局变量。 所以你当然要小心。
All of those sound like they would work. I figure which one you choose depends what your requirements/needs are. (Really unique and informative answer, huh?)
Your question was "What have others done?" though. So, if you're polling, I have used the constants approach for smaller applications recently. I haven't done an enterprise MVC app yet, but I figure I would probably make a base class that inherits Controller and defines those extra properties. And if I wanted to pass those consistently to the view I would similarly have a base class for my models. However, this would have to be used judiciously--even if you formally type them, they still act a lot like globals. So you have to be careful of course.
最后,至少对于这个应用程序,我选择了一个基本的 AppViewModel 类。 Controller.OnActionExecute/ed 查看 ViewData.Model 是否已设置,如果未设置,则将 AppViewModel 的实例放在其位置,以便所有页面都有一个一致的模型可以使用(Model.Title、Model.IsAuthenticated、Model .User 等)
然后,更详细的控制器操作有一个 AppModelView 的子类,它可以在操作本身中手动设置为 ViewData.Model,也可以通过属性在 OnExecute/ed 中设置。
根本没有太多代码,但它可以避免在所有控制器操作中重复相同的旧创建/设置代码。 对我来说,它将视图数据保存为一个包,而不是弄乱 Controller api。
In the end, at least for this app, I went with having a a base AppViewModel class. Controller.OnActionExecute/ed looks to see of ViewData.Model is set and if it isn't, an instance of AppViewModel is put in it's place so all pages have a consistent Model to work with (Model.Title, Model.IsAuthenticated, Model.User, etc)
Then more detailed controller actions have a subclass of AppModelView that gets set to ViewData.Model either manually in the action itself, or set in the OnExecute/ed via an attribute.
Not very much code at all, but it keeps from repeating the same old create/set code in all the controller actions. And for me, it keeps the view data as a package rather than cluttering up the Controller api.