Объекты в ViewBag - PullRequest
       10

Объекты в ViewBag

1 голос
/ 30 марта 2012

Я начал использовать MVC 3, и мне действительно нравится работать с ним.Это намного лучше, чем WebForms на многих уровнях.

Однако у меня есть вопрос о ViewBag (новый ViewData). Я очень осторожен, придерживаясь методов моделирования звука, где я склонен помещать все, что нужно моему представлению.в ViewModels.Однако, что касается ViewBag, есть ли какие-либо проблемы, кроме плохой практики моделирования, которая предполагает, что ViewBag следует использовать экономно?Я сам этим не пользуюсь, но товарищ по команде задал вопрос сегодня, и я мог бы только порекомендовать ограничить его использование, так как это слабо типизированная модель, взломанная, чтобы быть крутой с помощью динамического (sudo typed)

Форму, что я могу сказать, не должно быть никакого влияния на производительность от его использования, хотя?Я прав?Это просто еще один объект, который применяется к представлению на стороне сервера.Я не считаю влияние производительности на динамическое использование (если оно может быть измерено)

Как вы оцениваете недостатки (или даже преимущества) использования ViewBag?

Ответы [ 2 ]

2 голосов
/ 30 марта 2012

Для меня большая проблема в том, что ViewBag не является типобезопасным и может легко генерировать ошибки во время выполнения, если вы не будете осторожны.

Сумка для просмотра действительно удобна для предотвращения простых случаев, когда в противном случае вам понадобится новая модель. Я обычно использую их, но только для очень простых данных.

0 голосов
/ 30 марта 2012

из моего поста по адресу: http://completedevelopment.blogspot.com/2011/12/stop-using-viewbag-in-most-places.html

Even the built in templates give us support for ViewBag. The scaffolding templates create ViewBag.SomeEnumerable to use for our pages.
Sure - its quick code and since it's auto-generated will likely work ok. The problem comes in from the fact that ViewBag is a dynamic object. There are no compile time type checks. If you misspell something you won't be notified from the compiler.

I've seen this used in such bad ways, I would love to see it's usage curbed and applications cleaned up. 

So in a controller:
ViewBag.SomeProperty = "10"
and in the view:
@ViewBag.Som3Pr0p3rty
We won't ever know of this error. It won't even generate a runtime error since the misspelled name just generated a null.


Use ViewModels and save yourself from these potential problems. Our templates set a page title in ViewBag as well.


There are several options in setting a page title. Since this is a well known property one could argue that using it just for Title is ok. I wouldn't argue this. There are other options.
1. Set it in a section in the layout and render it from the client.
2. Use ViewBag.Title
3. Use a filter (seems much too complicated for a title)
4. Use a Model.Title field.

Since by default we have a ViewBag.Title field created and our templates also get it by default, I'll yield that in this case, its ok.

What about select lists?
Rather than the default 

 ViewBag.CustomerId = new SelectList(db.Customers, "CustomerId", "FirstName", order.CustomerId);


Do something like
yourViewModel.Customers = customers; //a loaded collection

and in your view
@Html.DropDownListFor(x => x.CustomerId, new SelectList(Model.Customers, "CustomerId", "Name"))

Or if you prefer to set your ViewModel to contain the SelectList


yourViewModel.Customers = new SelectList(db.Customers, "CustomerId", "Name", order.CustomerId);

and now your view would be slightly cleaner as:
@Html.DropDownListFor(x => x.CustomerId, x.Customers)

See, that's not so difficult now is it? Enjoy!
Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...