This is part 1 of my
compare the most popular frameworks and provide some recommendations on how to
What is an MVC Framework?
Many ASP developers
have heard of MVC or similar terms like MVP, MVVM when talking about ASP.net
MVC, a second-generation, Ruby-oriented server side development system. This
causes a lot of wrong concepts, which I would like to clean up.
#1 MVC is not a
Many developers hear
of 3 tiers (data, business, view) and think that MVC somehow reflects these
three layers (data=model, business-layer=controller, view=view). This leads to
some very creative code-structuring, but it's wrong.
#2… it's a way to
split the View-Layer
In reality, the
View-Layer has been getting more and more attention as the layers beneath it
get automated. Thanks to technologies like Entity-Framework or PetaPoco a
developer spends very little time in the DAL (data access layer) - and most
web-applications also have a very meager business-layer. So this is where MVC
fits in the 3-layer scheme:
Why split the
There are a few
reasons, but the most important is that as views become more complex, it's
important to apply the SoC-pattern (separation of concerns). This helps manage
the code and keep things clean. It also allows developers to automate certain
aspects (like url-to-view-mapping) in a consistent, clear way. And this
separation also allows automated testing of parts of the code - which is almost
impossible in the everything-is-together jumble.
What's a Controller?
Simply speaking the
controller decides what data is shown with what view, and how to handle
data-changes in the UI (the controller could decide to show/hide something or
to save data to the backend).
What's a View?
This is the Template
to be used for displaying the data to the user. It's typically some mix of HTML
and various placeholders.
What's a Model or a
The model is neither
the database nor a copy of the data in the database - it's actually the
data-currently-relevant-to-the-view. So it can contain database fields, but it
can also contain things like "show-details-pane" or
"user-input-is-valid" states. The model can also contain data from
multiple sources and calculated fields. I haven't figured out why it's called a
model - if you know, post it below. For more infos, I found this great article covering the model.
It's a system which
allows to you combine data (usually delivered as JSON) with some templates
(usually HTML + placeholders) within the browser and wire-up clicks and other
actions to do things you want to do. It helps you organize your code into
"data", "visuals" and "rules/logic" and
drastically reduces the amount of time needed to do this.
Such a framework
also helps with many standard problems like async data-loading (very common),
choosing which view to show and helps really separate the work, so that the
developer can program the logic without having to design it, and the designer
can make it nice without needing real programming skills.
The most common
today are probably:
And also popular, but mainly in the Microsoft ecosystem:
Kendo UI Core
Why not use ASP.net MVC?
There's an old ASP.net MVC-Framework, why not use
Good question. In
short: it's an concept which had a lot of trouble taking off, because it ended
up placing parts of the MVC on the server and parts of it on the client. This
spreadeagled approach inherited many of the ASP.net Webforms weaknesses. The way
I interpret Microsofts current work on ASP.net vNext, I believe it's dead and
expect the UI to react immediately to any kind of action. So if you click on a
thumbnail, you expect a lightbox immediately, and if you type in your ZIP-code
you expect a "this is the wrong-format" hint to appear without delay.
and does not benefit much from HTML-rendering on the server.
Now ASP MVC tries to
keep some parts of this rendering on the server - with very little benefit to
the whole solution but with a lot of overhead, debugging and more.
Simply put: JS MVC
works without needing ASP MVC, but ASP MVC can never be good without JS MVC. So
why bother with both, if one solution is simpler and does it all?
We see a rapid shift
from server-code to client code, mainly because it can't kill the server.
In old-school programming on DNN you would create a module with all the overhead
this contains - and with a DLL! This DLL can easily stop your DNN from
functioning and will be one of your core problems in every DNN-upgrade and
cause compatibility problems with other DLLs. In addition to that, a problem in
your DLL can stop DNN even if your image-rotator is not used on any page. The
advent of server-safe apps, with ZERO server code, will remove this problem
This is the Future, so you need one - now!
Just to be clear:
the entire web is moving this way - and even Microsoft has realized this and
has been secretly shifting in this direction for about 3 years now. I've
written a series about this called The Future of DNN Speaks Razor.
So it's never to
early to start - especially since other CMSs are already placing a strong focus
on this and DNN8 will too.
In the next parts of
this series we we'll look into
What is it and why you need
it (this post)
Comparing the currently most popular
frameworks AngularJS and knockoutJS
A simple example how to use
such a framework
- The entire setup with data-delivery from the server - ideally without server code
Discovering some sample Apps
for you to adapt to your needs
Daniel, Raphael and Benjamin