Why Opt for “Modern” – Viewstate, Postbacks, & User Experience
You may wonder why this trend has occurred. The real reason is frustrating user experiences! Though to technically speak about it one reason is that a lot of earlier written .NET applications usually contained a lot of server controls on their pages. These server controls created more and more viewstate on the page and more and more “round trips” (requests) to the server. If you're not familiar with viewstate check here for more info http://en.wikipedia.org/wiki/ASP.NET#View_state .
Even though apps are now using these front-end libraries they still need to get data from the application’s database, in our case... our module needs to get data from SQL. This is where web services come into play and, more importantly to us, the integration of Microsoft's Web API at the core of the DNN Framework. Microsoft WebAPI is a web services framework that allows us to expose data on end points that we can consume within our module and from anywhere else if we choose! This exposed data can be in many formats, but most commonly it is exposed as XML or JSON.
DNN has wrapped the Microsoft Web API with a DNN wrapper that makes it easy to work with the Web API within DNN meaning that you still have access to all the DNN goodness (API’s, info, etc.) from within your module and you still get the security benefits that DNN provides.
The majority of DNN module development tutorials that you'll find online are based on the way modules were built over the past few years. Though, there are some tutorials on what is known as "modern module development" out there. Check out DotNetNuclear.com for a few examples.
I have discussed all this to let you know that at this point in the series we're going to opt for the "modern" development route in this series. If you remember from the previous blog entry about coding and designing the view I made a mental note that we were using HTML controls versus .NET server controls and this is exactly why we did it that way.
Our module won’t be 100% client-side, but the point is that we’re going to reduce the number of sever controls included in our module to as few as possible all in the name of user experience & faster load times. So we are going to expose our task data via DNN's Web API Services Framework and then we're going to grab it, serialize it to JSON, then use JQuery AJAX to bind each JSON object to dynamically created DIVs in our module (Sounds geeky huh :-) ). Now if you're a front-end developer then we're starting to speak your language and you're probably licking your chops right about now, but if all that sounded like Spanish to you don't worry, we're going to go over all of that in upcoming blogs as well.
Since we're opting for the “modern route” of module development our next step will be to create the Web API Services for our module... and we'll do that in the next blog entry. Hope to see you there!
Go to the Next Blog Entry: "Creating the Web Service Class"