What is the best way to populate ViewData for the dropdownlists which are used in multiple views. If it is done in each and every Action that uses the dropdowns then we are violating the DRY principal. Also ideally we should be caching the regularly used SelectLists (e.g Countries, States etc).
A:
You should prepare base view model for these views and enhance it by inheritance with data from specific view:
class BaseViewModel
{
List<string> Countries;
List<string> States;
}
In my application I created an object that holds cached dictionaries. It implements IApplicationCache interface (created by me, it returns lists of used dictionaries), which is injected into business logic layer and used to populate view models.
LukLed
2010-02-14 16:32:40
But we still need to repeat the population logic in each and every action that uses the Select lists.
Amitabh
2010-02-14 17:04:47
@Amitabh: You can populate it in view model constructor or define external method that does it and call only that method.
LukLed
2010-02-14 17:14:47
How is this going to work if I am using DropDownList as a UIHint in Templated Html Helper?
Amitabh
2010-02-14 17:50:34
@Amitabh: I don't know much about UIHintAttribute, you'll have to check if it is possible to pass part of the model to view responsible for showing dropdown. I'll try to check it.
LukLed
2010-02-14 19:05:31
+2
A:
I've done it before with ActionFilters. In my case, I needed a list of sponsors on every page.
Patrick Steele
2010-02-14 16:46:31
Although its a clean solution but I have too many common SelectLists. I don't want to create 5 different filters. Is there any better way then filters.
Amitabh
2010-02-14 17:02:40
"Better" is a relative term. By creating 5 different filters, you'd have maximum flexibility in deciding which actions and controllers need a specific set of data in ViewData.Actually, you could probably create a single filter that accepted some parameters (perhaps a list of enums) that would indicate which dropdown data needed to be put in the viewdata. I don't like it as much as individual filters, but it would get you to a single filter.
Patrick Steele
2010-02-14 17:25:31
@Patrick Steele The problem is attribute space is at a premium in ASP.NET MVC and without being careful you'll end up with more attributes than lines of code in your controller.
jfar
2010-02-14 17:32:38
@jfar: Agreed, I could see the possibility of that happening. But is that a problem? It definitely would look odd to me if I saw more attributes applied to a method that lines of code, but I'm not sure I would immediately equate that as a "bad thing". To be honest, it's nothing I've thought about that much. Interesting...
Patrick Steele
2010-02-14 21:23:00
@Patrick Steele Your right its not a problem nor a bad thing and I didn't say or imply that. I was just trying the share my and I think Amitabh's concerns. Maybe its just a pedantic quirk of mine that MVC almost encourages having tons of attributes. Really it could be considered a good thing as it lends to separation of concerns.
jfar
2010-02-15 06:54:13
@Patrick My only concern is that is the filter attributes good place to populate ViewData??
Amitabh
2010-02-15 10:29:11
@Amitabh: I think it's an acceptable place. It's testable and extensible with very loose coupling. Plus it allows fine-grained control of when the data gets loaded (i.e. you can skip applying the atttibute to json or other non page-related actions).
Patrick Steele
2010-02-15 17:11:46