Why is this important? Because ASP.net WebForms is dead! And with this, the alternative ASP.net MVC may become irrelevant. Yes, there will be a new version - and it will be better than WebForms. But...
We have to develop today for the future
Right now we (2sic) are working on various projects on DNN and SharePoint - and all these projects have one thing in common: All of them run on "old" technologies which are officially dead (ASP.net WebForms). But when our customers pay thousands of $$$ to do something then I want to guarantee that the money isn't wasted. The only way I can do this is to develop something that works on WebForms AND MVC.
And this basically means: I don't really rely on server HTML-assembly capabilities. Neither in SharePoint nor in DNN. Because if I do use server-html-rendering, then I cannot guarantee an upgrade in 2 years time.
Is it better to use ASP MVC? Maybe. The way ASP.net is evolving (.net core etc.) I can guarantee that Razor is here to stay, and WebAPI as well. My very personal opinion is:
- WebAPI will stay and become the cornerstone of all web development
- Razor will stay and be the primary server-side html-rendering to deliver the basic page
- DNN-Tokens will stay and be the preferred server-side-html rendering because it's safe (no code injection, no security breaches)
- Server-Side-MVC (so the concept of handling HTML-Rendering and Click-processing on the server) will become a rare use-case. The core weakness is the user interaction handling which just doesn't make sense on the server (slow, messy, hard to develop, hard to test, uncool, not portable to other systems) - and when you stop handling clicks on the server, then much of MVC becomes irrelevant.
IMHO this is how it must work in the Future
There are basically two types of applications/modules in a CMS. Output-oriented Apps (to display content to users) and data-changing Apps (where users interact with the content to change data in a database behind the CMS). We'll start with the more complex: the apps with user-interactions:
- Principle 3: If we assume that the Principles 1 and 2 are correct (and I would love to hear opposing views with good reasons contradict me) - then the entire UI will be built on the client. The only thing the server actually has left do to is
- Provide a clear WebAPI - in most cases this will be a generic REST API which will not require any coding
- Provide a data-storage and caching system - in most cases this will be generic and not require coding (like SharePoint or 2sxc)
- Provide a custom query system - either based on a REST-like schema (OData) or a configuration based Query Designer (I'm currently voting for the query designer because OData would pose difficult security challenges to only allow certain types of queries)
- Handle security related issues which cannot be delegated to a client - in most cases generic / configuration-based (no-code)
- Provide an initial context for the app to start with - for example DNN-Modules need a Module-Id, the correct scripts and some initial simple HTML
Assuming these 3 principles are correct (and nobody has managed to point out the flaws so far), then the server will just generate some initial state, parse simple HTML-templates, provide some data etc. - all generic actions which require simple templates but little or no code on the server. Based on these 3 principles, the act of supplying a Complex User-Interaction App becomes the same as supplying a Simple Content-Output-App.
So let's look at the simple Content-Output-App:
- The server must retrieve some data (the content) and some state...
- ...the parse it through a template to create some HTML
This can be done in ASP.net MVC - but why bother? It's such a generic, common use case that various systems give you the ability to do this without wasting time with writing data-layers and controllers. There will be 2-3 such generic system and these will cover 95% of all use cases. Foremost I would like to mention (our) Open-Source 2sxc, but others are also working on such solutions like Sasha with OpenContent + some for-pay-options in the DNN-Store. Maybe DNN will also provide such a framework in the near future.
MVC as a Concept will Stay for all...
To be clear: the server will use MVC separation of concerns (SoC) meaning the separation of the data=model from the view=template and the controller=system-connecting-this. But I'm convinced that in 95% of all cases it the App-developer will only spend time on the View and get the Model and Controller for "free" from a tool like 2sxc or OpenContent.
...Custom WebAPI will be needed in 10% of all cases
All Content-Output-Apps will not need WebAPI, and most input/output Apps will use generic REST. So in about 90% of all cases the developer will not write any server code at all, and in about 10% of the cases where normal REST doesn't suffice (for example 1. uploading files or 2. cases where extra security-checks are needed when updating parts of content-items or 3. when you want to run custom workflows on the server) then the developer will create some custom WebAPI. But this will be the exception, not the norm, and as the generic stack gets better, the need will become smaller.
...Server-Side ASP MVC for Pages is only for 5%
Since probably 95% of all cases can work with a generic Model/Controller system for rendering HTML, then only some very exotic cases will actually need real ASP.net MVC as a page-generating system. Will an image-gallery need this? Nope. Job-listings or real-estate? Nope. Blog? Unlikely. FAQ? Not a chance. Line-of-Business-Apps? I don't think so.
In another post I'll tell you more about how we learned these things developing for SharePoint, and how we transferred this learning to our DNN work.
With love from Switzerland,
Daniel Mettler grew up in the jungles of Indonesia and is founder and CEO of 2sic internet solutions in
Switzerland and Liechtenstein, an 20-head web specialist with over 600
DNN projects since 1999. He is also chief architect of 2sxc (2SexyContent - see forge), an open source module for creating attractive content and DNN Apps.