Search code examples
asp.net-mvcspark-view-engine

Changing the View Engine in Asp.NET MVC


I am trying to learn ASP.NET MVC by porting my current app written in ASP.NET Webforms to MVC. For starters, I am planning to use the Default View Engine (WebFormsViewEngine) as most tutorials/examples and the book I have use that as the default.

However, I know for sure that I do not want to use WebformViewEngine in the future and once I have a grasp of MVC, I would like to switch to a different ViewEngine (Spark seems to be interesting)

Would this be a simple change or would it take a lot of effort in terms of coding new views? What I basically want to know is which would involve more effort? Learning an alternate ViewEngine now or switching later?


Solution

  • OK - firstly you've got a decent sized investment in WebForms I'm assuming, and by virtue of that, you'll have a fair amount of user controls on existing forms etc. I'm sure you already know that this in itself is going to be the most work in the process, and has nothing to do with which view engine you choose because even the WebForms MVC view engine doesn't support user controls directly. This part of the work will still need to be done regardless...

    Secondly, you probably are looking for a view engine that can take most of your other view built in logic and code (i.e not user controls), and by that I mean the stuff between the bee-stings ( <%= blah %> ).

    Obviously the WebForms view engine does support this same syntax, but you also say that you specifically don't want to use the default WebForms view engine. Well you'll be happy to know that Spark also supports the <%= blah %> syntax, and this has been done specifically to support migrations like this.

    Your best bet before deciding would be to watch this recent video here, and see how Louis goes through the simple WebForms-based MVC solution and it keeps running correctly even though the code still contains <%= blah %> syntax.

    This support makes it much easier to transition and when you're ready you can then start moving your code to the more recommended way of using ${blah} syntax instead. But this can be done at your own pace whilst the overall functionality still works.

    Hope that helps,

    All the best,

    Rob G