Derik Whittaker

Syndication

News


Images in this post missing? We recently lost them in a site migration. We're working to restore these as you read this. Should you need an image in an emergency, please contact us at imagehelp@codebetter.com
ASP.Net MVC ViewData best practice open question

This is post is more about me asking the question then giving direction on best practice.

The question is simple.  When dealing with viewdata with the MVC framework, what type of usage of viewdata is preferred?

Approach 1

If you watch Scott's screencasts it appears the he favors the use of a property object that is unique to each view.  This property object would hold onto the various objects needed by the view.  By using this method, you are assured that the view is typed.

i.e. public partial class SomeView : ViewPage<SomeViewPropertyBag>

This method allows for the view to be strongly typed, but also would require that you actually have a shell of a code behind class as well as a special class for each view.

Approach 2

The other approach that I have seen is from the CodeCampServer guys.  They have implemented their own 'smartbag' (a typed hashtable) which they use as a catch all object to be used by the view.  In this case the developer is getting data out of the smart bag blindly (meaning they are not 100% assured that the object type they want/need is actually meant to be stored in the smartbag for that view).  This method does NOT require the use of a codebehind page though, so that could be a plus for some.  It also does not required a special class for each view, this could also be a plus.

Thoughts, feedback.  Just wondering here.

Till next time,


Posted 03-06-2008 8:55 PM by Derik Whittaker

[Advertisement]

Comments

Christopher Steen wrote Link Listing - March 6, 2008
on 03-07-2008 7:57 AM

ASP.NET ASP.NET Team Releases for Mix 2008 [Via: podwysocki ] Link Collections Interesting Finds: March...

Ben Scheirman wrote re: ASP.Net MVC ViewData best practice open question
on 03-07-2008 10:02 AM
Let me chime in with some points. 1) if you use NVelocity or brails you don't get intellisense anyway so this problem just doesn't really matter anymore. Using a plain dictionary works. 2) SmartBag works well with heavy convention, but you kind of have to do it or not... it's difficult to choose on a per-view basis. Additionally, everyone must call RenderView in a specific way so that the right SmartBag gets passed (you might need to load stuff outside of your action method -- like in a pre-action handler or a filter) -- thus you need to be rendering the same smartbag that was available to the other steps. 3) the view-specific view data is what I'm leaning towards, but I'd like to see the ViewPage to reside in the page directive, not a code behind.
Derik Whittaker wrote re: ASP.Net MVC ViewData best practice open question
on 03-07-2008 10:34 AM

@Ben,

I would agree, not having to create a code behind simply to put the ViewPage data would be nice.

Has anyone suggested this to Scott and his team?

Ken Scott wrote re: ASP.Net MVC ViewData best practice open question
on 03-07-2008 2:39 PM

One advantage that I see to how ScottHa is doing things is that you can have more than one item of a given data type.

With the SmartBag, the key is the type, so if you have two strings to pass in, you have to create a type for those strings anyway. That might be better in the long run, but it is still one small ding against the SmartBag that I have run into.

Keith Klein wrote re: ASP.Net MVC ViewData best practice open question
on 03-07-2008 9:57 PM

Another approach I haven't seen talked about much is the DictionaryAdapter that grew out of the Monorail project. If you have an interface describing data your view needs, a DictionaryAdapter generates a class at runtime (emitting IL) that implements your view interface. The class it creates is just a wrapper around a dictionary.

So there's no need to create a separate view data class for each view - just an interface, and you get strong typing. Not sure about what kind of performance hit you take for this. I believe it caches the generated class once it's created...

About The CodeBetter.Com Blog Network
CodeBetter.Com FAQ

Our Mission

Advertisers should contact Brendan

Subscribe
Google Reader or Homepage

del.icio.us CodeBetter.com Latest Items
Add to My Yahoo!
Subscribe with Bloglines
Subscribe in NewsGator Online
Subscribe with myFeedster
Add to My AOL
Furl CodeBetter.com Latest Items
Subscribe in Rojo

Member Projects
DimeCasts.Net - Derik Whittaker

Friends of Devlicio.us
Red-Gate Tools For SQL and .NET

NDepend

SlickEdit
 
SmartInspect .NET Logging
NGEDIT: ViEmu and Codekana
LiteAccounting.Com
DevExpress
Fixx
NHibernate Profiler
Unfuddle
Balsamiq Mockups
Scrumy
JetBrains - ReSharper
Umbraco
NServiceBus
RavenDb
Web Sequence Diagrams
Ducksboard<-- NEW Friend!

 



Site Copyright © 2007 CodeBetter.Com
Content Copyright Individual Bloggers

 

Community Server (Commercial Edition)