On the limitation of ASP.net MVC in the front-end development

asp.net MVC

If you haven't reached the end of the MVC framework, take a look at the ASP.net MVC code below and see how back-end MVC works. It is excerpted from the very famous Project MVC Music store section of the ASP.net MVC Tutorial Controller component code:

public class Storemanagercontroller:controller
{
    private musicstoreentities db = new musicstoreentities ();
    Get:/storemanager/public
    viewresult Index ()
    {
        var albums = db. Albums.include (a => a.genre). Include (a => a.artist);
        Return View (albums. ToList ());
    }

    Get:/STOREMANAGER/DETAILS/5 public

    viewresult Details (int id)
    {
        Album Album = db. Albums.find (ID);
        Return View (album);
    }

We know that one of Controller's responsibilities is to respond to the user's behavior on the view, and how each behavior responds to the controller specific method, which we can call action. The two public methods in the above Code, index () and Details (), are two action. They all belong to Storemanager this controller. If you have a ember.js that uses the front end, you should be familiar with these two concepts.

But the question is, how do you correlate the behavior of the user in the view with the method action that responds to the behavior? Even associated with controller? A URL is one of the methods. The comment on each action on the above code represents the URL for this action. That is, when the user clicks on the URL, the router service in the framework can parse out which controller to call and which action under the Controller to respond to by the URL, and, for example, know that the URL's rule is { Controller}/{action}/{id}.

So what should be the result of the response? From the above code Viewresult and Return view (), you can see that two action returns a new view.

One of the most familiar examples of an existing MVC site is GitHub. You will find that you have a unique URL for each click on the GitHub site, and the result of each interaction is that the server returns a new page. It uses very little JavaScript, such as when you choose to edit, and it jumps to a new page instead of popping an edit box on the current page.

Why the first thing to talk about is the characteristics of so many server-side MVC frameworks. Because the next step is to look at the MVC framework in front of you, you will find that there are a lot of differences.

Javascript MVC

As can be seen from the above, the server-side MVC framework serves the entire site, which relies on constant return pages to respond to user requests, so router services are critical. The front-end pages that use the MVC framework, most of which are single page application, are not even as simple as one, but only one component on the page, such as a slide. Therefore, it is not realistic to convert the user's behavior to a URL. You might say that it's really impossible to produce new pages, so how about reducing the granularity of the pages? That is, on the server side a URL map is a page, then we map the URL to a page of a region or function?

For example, the following section of the Backbone.js ToDoList applied router as an example:

var todorouter = Backbone.Router.extend ({
    routes: {
        ' todo/add ': ' Add ',//new Item
        ' Todo/edit/:id ': ' edit ',// Edit Item
        ' todo/remove/:id ': ' Remove ',//delete item

        ' filter/completed ': ' filtercompleted ',//filter out completed
        ' filter/ Uncompleted ': ' filteruncompleted '//filter out of unfinished
    }
    //Todo
});

If we follow this route plan, we want to have a new input box when the user enters Http://example.com#todo/add, and when the user enters the http://example.com#todo/edit/ The 123456 page appears with an edit box that edits the note for ID 123456. This reduces the URL-mapped page granularity to the size of the input box.

But this will cause another problem, pay attention to the above route difference: todo/Domain name operation is a single record, and filter/domain name under the operation is to filter the list. So also have to consider a situation, if the user wants to filter in the case of each item can be operated? If allowed, refer to the permutation combination, route do you want to add 2 x 3 = 6 items? such as the new Http://example.com#filter/completed/todo/add route.

Such a setting is obviously unreasonable. The problem arises because the URL is one by one corresponding to the page in the backend. If you reduce the granularity of the page, you can't match the page functionality to the URL, or it's too expensive to have URLs cover all the features on a single page.