views:

253

answers:

1

I'm using Asp.net MVC 1 and I would really like my controller actions to use StronglyTyped View(data) calls that enforce type checking at compile time and still let me use aspx pages under the default view engine. The ViewPages I call are strongly typed, but errors in the action's call to View(data) can't be caught at compile time because the built in Controller View(data) method isn't strongly typed and doesn't even check to see if the page exists at compile time.

I've implemented a partial solution (code below) using this post but (1) I can't get the generic View function to recognize the Type of strong view pages unless I create a code behind for the strongly typed view, and (2) Intellisense and refactoring don't work properly with this method which makes me doubt the reliability of the method I'm using.

Question: Is there a better way to get type enforcement when calling Views from actions?

Alternative: Is there an alternative method where my action method can create an instance of a viewpage, set some properties directly and then render out its HTML to the action response?

Code: Here's the base Class all my Controllers Inherit from to achieve what I have so far:

 public class StrongController : Controller 
    {

        protected ActionResult View<TView, TModel>(TModel model)
            where TView : ViewPage<TModel>
            where TModel : class
        {
            return View(typeof(TView).Name, model);
        }


    }

And here's an example Controller in use: namespace ExampleMVCApp.Controllers {

    public class HomeController : StrongController 
    {

        public ActionResult Index()
        {
            return View<ExampleMVCApp.Views.Home.Index, ExampleData>(new ExampleData());
        }


    }
}

ViewPage Code Behind Required for Type Recognition... Aspx header didn't work

namespace ExampleMVCApp.Views.Home
{
    public class Issue : System.Web.Mvc.ViewPage<ExampleData>
    {
    }

}
A: 

I think you should give the T4MVC helpers a spin (one of the original announcements here). This would at least enable you to get rid of the code you already have, since these templates generate the code based on the Views you already have and you employ these "fake" method calls to address your views.

For having your calls to View to be strongly typed for the specific model declared by your view, I am not exactly sure if these helpers help you with that (though I suspect they do). However, if they don't you can still hack the T4MVC code to do so yourself or get in touch with the original author, David Ebbo, to suggest the feature for addition.

paracycle
Thanks for the suggestion. I'm going to check these out and report back whether they worked for my situation.
Glenn
I spent a couple hours playing with T4 and the MVC futures html helpers. T4 is nice and generally worked well. However, the auto gen code it makes barfed on me a several times as I refactored my code with strange compile errors and from the blogs on its construction the whole tool seems difficult to maintain. I'm going to keep using a combination of my method above and possibly some lambda functions until MVC core provides a better built in method. Conclusion: I think your T4 suggestion is a very valid option, I'm just going to err on the side of keeping things simple and stable.Thanks.
Glenn
Thanks for the feedback. Having not used the T4MVC helpers myself, you got me curious as to if its View helpers are strongly typed or not, out of the box. Could you give some feedback on that?
paracycle
Inside a View I think the answer is mostly yes, I didn't have much success using it to strongly type my calls to render views from the controller. I didn't give it the fullest set of tests that I could have because as I was changing my data classes and views around to test it I caused lots of compile errors that had to be manually cleaned up and that was enough to dissuade me from using it. Also, I couldn't find any clear examples of other people using it as the seamless solution I wanted and I'm hopeful Microsoft might update VisualStudio next year with a better system.
Glenn
Mainly I'm hopeful the default aspx driven view engine gets an overhaul so that all views are fully compiled and type checked. If they did that then the need for magic strings, anonymous objects and code auto gen tools goes away.
Glenn