Why transition from Web form to MVC

It can be said that in the next few years, the use of Web forms will gradually decrease, and instead of MVC. You may not agree with my point of view, so I will try to elaborate on my point of view. If you still cannot accept it, please Refute me.

It takes time to learn a new language or new architecture. Do we need to abandon the original in-depth and skillful architecture to cater to the new architecture? Yes. If I want to say whether my answer is yes, but I need to check whether the new architecture and the original architecture have been improved, do we really need to invest a lot of time to learn? Mvc is an architectural model that brings a brand new development experience that is the same as that in the asp era (Note: I am not saying this is a backend ).

Next I will explain whether MVC is worth learning for Web form.

1. View State

I believe everyone is familiar with this view status. It is used to save the data status we entered on the page, so that we can make the page Return to the status of our original input data when refreshing the page or sending back. This effect is very good for our needs. But at the same time, let's ask ourselves, do we really need this? Is it meaningful to display the original data when the page needs to be refreshed?

In addition, View State is widely used in the web form era. It exists on every page, and even has a large size in complicated pages, the View State will be passed during each page sending back. We do not say that it takes time for the server to parse these View states, that is, the bandwidth will increase when these View states are passed during each page transmission, it takes longer to display the web page. In the 2.0 era, at least I cannot.

2. Page Life Cycle Page Lifecycle

There are complex lifecycles in Web forms. I even clearly remember that when I learned Web forms, I drew these cycle diagrams on paper with a pen, what actions will be performed on each cycle page. This is like writing SQL helper when I am learning c # to connect to the database, which makes me a headache. For example, you should not access the specific control in Page_render (), because the control has not yet been generated. (Some garden friends made an error and I thought it was wrong when I checked the information, this is because the control rendering has to be output. Thanks to the school friends for making the mistake, I will actively correct it). If you want to access it, please contact the Page_load () event every day in Page_Load (). At least I often. IsPostBack is a common method.

If you think you can fully master these lifecycles, you are at least a master. If you can control the lifecycle of a page and control the generation of controls at will, I will respect you very much.

3. False sense of concerns failure separation of concerns

Now we do software, focusing on maintainability, reusability, and separation of focus. What is separation of focus? My understanding is that each layer structure is only responsible for his own affairs. It does not belong to him and cannot be controlled. For example, we wrote the database access code in code behind and called the class in SQL helper. But now the database server service is not enabled, so this call will certainly throw an exception. Let's handle these exceptions in code behind, so our programmers will be exhausted. The exception should be handled in SQL helper, not code behind. This is the so-called separation of concerns. In addition, separation of focus should be that each class is only responsible for his own work, rather than returning html statements in a class SQL Helper.

4. Limited control over HTML has very low control over html

As I said in the page lifecycle, if you can change the generated control at will, I will worship you. It is very difficult to say that a server-side control can control the html style or generate the html ID and name so that javascript can be used. Of course, a property is added to. net 4.0, that is, ClientIDMode. If this attribute value is set to static, an html ID value with the same ID as the defined ID can be generated. By default, this feature is disabled and generates complex and nested ID values. This is very difficult for us to operate html tags on the client.

Of course, this is not the reason you can switch to MVC, but it is one of the reasons, although this may be a little far-fetched.

5. Leaky weak action abstraction

Web form tries to hide all http states (non-memory or stateless http ). When we drag a server control, we always need to consider when it will display it? Because the server control has implemented these functions, for example, why can the IsPostBack method be used to determine whether a page is sent back? What is its implementation principle? We don't care. We only care about what this method can accomplish. Is that enough? Is that enough?

I don't think so. I think anyone who knows English can do it, but is it enough? Has the performance problem reached? What problems will occur? We don't know. We only use a black box, but we don't know what is in it? If it's a trap, will we jump in without hesitation? Right?

Occasionally get familiar with the source code. In addition to helping improve our own development level, we can also find many problems that we can control to prevent them from occurring? So, dear friends, don't just use it. Sometimes the fundamental difference between a calf and a calf is that the calf doesn't know why? Daniel guides how to better do this.

6. Low testability: extremely poor testability

When I used to develop a web form, using server controls greatly improved the development speed. However, I never know how to test whether the code I developed runs normally. The only way is to click, click, and then click when you are fine. Another is to set the breakpoint, hold down F11, and constantly click the keyboard until you can see the code to vomit?

But in MVC, these problems do not exist any more, because we can use Nunit and other tools that can perform unit tests. We can precisely test each line of code, we can automate testing to avoid wasting a lot of time manually clicking. This is a good thing, isn't it?

Also, I personally think the most important reason is that if you have a web form Development Foundation, learning MVC is very simple, because MVC does not contain server controls, some are only html tags and Some helper classes that can generate html tags. I personally feel that it is a good time for me to switch to development as an artist, because html is more familiar to programmers.

Without View State in MVC, you can fully control html. Instead of using the original Url rewriter, you can use the Route in MVC (Url Routing System ), A good separation of focus framework (Model, View, Controller), each layer is responsible for its own tasks.

In MVC, not every address has a specific page. You can define multiple actions and return the same page. Because of the powerful Routing System in MVC, we will not see www.cnblogs.com/default.aspx. this is the representative address www.cnblogs.com/home/index, which is a huge breakthrough. A specific page can have a specific meaning. This is URl-friendly. What do you think?

I am not saying that MVC will replace Web form, but the comparison between them. Of course, if we can avoid some problems, let MVC and Web from exist in the same project, maybe it is not a good choice. But the premise is that you still need to learn MVC. I personally think that Web form and MVC will coexist in the next few years.

Well, after talking so much about it, I just have one sentence: If you want to stay ahead of Web development in the future, study MVC in your spare time.

If you want your website to have better maintainability, it is wise to adopt MVC.

The above is just what I personally said. Please refer to it !!

Every day, a little progress will take a huge step in one year, and ten years will be successful. A gentleman shall strive for self-improvement, and a gentleman shall study hard and make progress every day. Reprinted Please note: http://www.shlongyingjixie.com