Introduction
Mmmmmm.... southern home-style cooking... I must have been hungry in the spring of 2013 when I came up with the concept of developing a restaurant menu module as a sample for the module development class that I taught at the Southern Fried DNN conference in Charlotte. I thought it was a good sample application to train developer who were new to DNN because it illustrated fundamental aspects of a real world module: data access operation (create, read, delete, update), module settings, and image upload.
Fast forward to early 2016 and I found myself in need of a demonstration to teach students at my module development class at DNNCon Baltimore. I decided to dust off my restaurant module and give it an update. I wrote it two more times using the new DNN8 development techniques, MVC and SPA. Then I posted all 3 modules, an updated version of the original Webforms module and the new MVC and SPA modules, on my github page.
Which technique do I use?
What are the reasons you would want to use one development technique over the other? I was able to implement the Restaurant Menu module with all three techniques. Let's discuss...
Webforms
I'm already familiar with this technique - Ok, that's not really a good reason, but many developers may continue to build Webforms modules just because they haven't updated their skill-sets and the DNN8 platform still supports this.
I am building a module for DNN8 that still needs to be compatible with DNN7 - If you are a vendor building modules for anyone, you still need to support the older versions. At some point, you may want to branch your code and move to a new DNN8 technique, but for now you are sticking with Webforms.
I like leveraging prebuilt Usercontrols like dnnLabel and dnnFilePicker - This is the nice thing about Webforms; the ability to compose our pages of other components. Sure we can do it with Partial Views in MVC and directives and partial views in a SPA/Angular modules, but many useful webforms usercontrols are currently built for us in the DNN core.
SPA
Forces you to use client-centric design - What does that mean? Since our module controls must be .html files, we have no choice but to put all of our business logic into the javascript and framework services. That's what a lot of us are doing with our webforms modules anyway.
Responsive UI - I'm not talking about mobile responsive here, although in my restaurant module, I did base the new SPA version on Bootstrap. What I mean here is not posting back the page makes the UI much snappier. And let's dispel the myth that the DNN SPA technique will automatically make your module a "Single Page Application". It won't; you need to use Angular partials or Knockout templates to achieve that moniker.
MVC
You can build complex business logic and unit tests - I see this as the strongest point for MVC development; building unit tests for your MVC controllers. In the Restaurant Menu MVC module, I provide a sample unit test to get you started.
Familiar web development pattern - To old-school ASP.NET developers like me, webforms is comfortable. But to people used to other technologies, the MVC pattern is more comfortable and familiar. I was recently training a young new developer at Bluebolt on Webforms and it was completely foreign to him. But he already knew MVC, NodeJS, Angular and other modern technolgies and patterns.
Free Code?
Yes, if you missed my link in the article's introduction, get the Restaurant Menu Module in its 3 flavors on my github page.