Alternative to .NET MVC and WEB Forms
As you know, web application development for .NET uses mainly two solutions - WebForms and .NET MVC. Surely there is something else, but these two solutions from Microsoft - the owner of the platform, the web server and the development environment.
Actually, the presence of only these two solutions in .NET is convenient in that it clearly demonstrates the difference between the component approach (WebForms) and MVC. On other platforms, the same layout, but on PHP, for example, there are so many frameworks that it is not always possible to understand what type of framework it is.
Comparative analysis of the above two .NET solutions is easy to google, so it makes no sense to stop.
')
Perhaps, the main problem of WebForms is the complexity of managing HTML-code and, as a consequence, problems for front-end developers. This flaw was “fixed” with the help of .NET MVC, having transferred full control to the programmer, with all the ensuing consequences.
I suppose the outrage of the MVC evangelists, but nevertheless I will express my conviction: MVC on the web is like a saddle on a cow. Of course, this is not about the general idea of ​​separating code, representation and data. It's about the typical implementation of the pattern in the web - controllers, actions and the whole architecture itself.
In general, the MVC pattern was coined for the desktop, and there it did not replace the components, but was used to build the application architecture.
One of the significant problems of MVC, as well as other non-component solutions, is the lack of ensuring the persistence (state of the elements) of a page between calls from the browser. In the good old WebForms, we set the form, for example, the checkbox and did not worry about how it will be drawn and how its state will be restored after a reboot. That is, the programmer did what he was supposed to do - the implementation of business logic, interacting with components through their backends, and processing events of page elements after user actions. Essentially the same as in the desktop.
MVC frameworks do not provide this automatically; therefore, the state of the page must be restored manually, and on complex pages (for example, a catalog with a basket, product selection filters, etc.) this task is not trivial.
The simplest example to demonstrate the seemingly contrived problem with persistence. A certain page with tabular data. At the top of the page is a filter form, for example, a date range and a Search button. Push the button. The action with parameters is called, the model is loaded, displayed on the page. Fine. Next - click, for example, on the link paginator or column header to sort. The corresponding action is called with the parameters ... oh, where is our date range? Go back, write it in the session (hang all the elements on the link paginator, etc.). And this is just a simple, albeit everyday, example. Separate problem of complex presentation pages: one huge with a huge controller and model, or a partition into modules, widgets, and how then to combine all this?
There are different ways to solve problems. For example:
- large models that include the whole page, which is absurd, because the model is, first of all, a business data model, and not a dump with page data;
- all sorts of hierarchical MVC type small MVC in one large. Even comment on this nightmare is not worth it;
- ViewState as in WebForms - this is still all right, but there are its own, more than once described, problems;
- asynchronous calls to the server without reloading pages up to the so-called SPA pages.
The latter option is much more laborious in development, but, nevertheless, has become very popular, although there is not the slightest reason for this. The truth of life is that the user doesn’t care how much it loads. Moreover: the user is usually annoyed that the type page has loaded, but something is not yet loaded there and it is not clear when and how it will be loaded. Plus browser brakes, especially when using client javascript frameworks, and especially on mobile devices. Of course, such problems mostly torment developers in all sorts of Silicon Valleys. For our users, the user or customer is a valenok, who himself does not understand what he wants, and our task is not to do as he requires, but to explain to him that he actually needs something completely different (as a rule, what we already know how to write). And he doubts - let him google that this season the angulyar and all kinds of reactants are the last beep, the trend and in general.
But then the question arises: for whom smart people have come up with cloud computing, if some push the logic onto the client (the argument in the form of saving tens of kilobytes at the current Internet speeds and cheap money is not convincing)?
In fact, these torments (or rather, perversions) are done only for one reason - to circumvent the problem of persistence of page elements. That is, they invented a crutch in the form of MVC, then instead of curing the limbs and abandoning the crutch, they simply added one more pair to it - client javascript frameworks.
Of course, there are sites like social networks or google where, as the main functionality, we need asynchronous data exchange, messaging and all sorts of notifications, but the percentage of such sites among the entire set of these is approximately the percentage of zakerbergs among all programmers.
What, in my humble opinion, should be done: take a component solution and solve the problem of managing HTML code without complicating the work of the programmer. Attempts of similar decisions are on other platforms. For example, the PHP framework Prado, but there the developers stepped on another rake - they began to create all sorts of custom tags for the front end, all sorts, and others like them. However, Razor with its “bird’s” language also does not delight the web designers.
An example of the solution we need is the Java Wicket framework, on the basis of which the Zippy PHP framework was made. In fact, the main architectural solutions were ported. In particular, pure HTML is used as the front-end and, of course, event-oriented component architecture.
We will not dwell on Zippy - the project has a home page and a repository on GitHub. Therefore, we return to what we started from - an alternative to existing solutions for .NET - the ZippyNet framework, as a result of porting from PHP (Wicket) to .NET.
The framework does not require either WebForms or .NET MVC libraries. Sources on github . In addition, the project includes a simple website preparation to demonstrate the configuration and operation of the framework and a page with some elements, as an example of use.
In short, the principle of operation.
Front end:
Back end:
How it works.
The back-end and front-end are associated with the identifiers label1 , link1 in the special attribute zippy . Passive templating is used. When rendering a page, an instance of the class of the corresponding component finds its tag in the DOM model (the CsQuery library is used) and changes its value or attributes in accordance with its data. At the same time, for event source elements, a special type of HTTP request addresses is formed, according to which the server understands which element was clicked or switched, that is, is the event source (when you first access the page, when an instance of its class is created, the URI contains the class name pages). And at the same time, no ViewState is needed - an instance of the page class with child components and, accordingly, their data is stored in the server session.
And by the way, about AJAX. Despite the fact that the need for asynchronous calls when using this framework is no longer necessary, nevertheless a number of components support asynchronous operation for those cases when it is necessary. Moreover, asynchronous work is provided by the same component approach. The developer does not need to program anything, much less stick everything, forgive, Lord, Angulyars and reactants.
All you need to do is replace the handler with setAjaxClickHandler. The link1 component when rendering a page template on the server will add an onclick handler with an AJAX request. When rendering an asynchronous response, the label1 component will respond with a javascript that changes its text value on the client with new text (something like $ ('# label1'). Text ('I am AJAX clicked')), which will be performed using eval (). You do not need to encode anything else.
It should be noted that AJAX requests, like regular synchronous, are executed in the context of the page instance (with access to the state of all page elements and their data) - unlike the MVC controller that is re-created each time.
This is the essence of the components - they themselves ensure the preservation of their state, interface rendering and event handling, depending on the context. The programmer focuses on business logic and the coder works with pure HTML. The components ensure the modularity of the project and, as a result, the scalability of the development. Components are easily extended by simple inheritance from the corresponding class with overloading of the necessary methods. For example, the date input component inherits the functionality of the text input element (for the tag), but when rendering it additionally generates a javascript line that assigns the tag to the DatePicker plugin from the jQuery UI. And when processing a request from the server, it converts the received values ​​into DataTime.
At first glance, the article - PR some kind of knee crafts, but this does not make much sense. Unlike most “cyclists”, I am a realist and I know that I will use my bicycles only - I wrote them for the implementation of my projects, which give me a piece of bread, much faster and easier.
But I would like to draw the attention of the community, especially newcomers, who are convinced that PLO and MVC are one and the same, that despite the presence of hot-air fashionable chips and all sorts of “trends”, there are often much simpler logical and natural solutions and it is not always worth running as a herd of lemmings just because this direction is indicated by some programming gurus or because Google is promoting the next JavaScript framework.
Actually, the presence of only these two solutions in .NET is convenient in that it clearly demonstrates the difference between the component approach (WebForms) and MVC. On other platforms, the same layout, but on PHP, for example, there are so many frameworks that it is not always possible to understand what type of framework it is.
Comparative analysis of the above two .NET solutions is easy to google, so it makes no sense to stop.
')
Perhaps, the main problem of WebForms is the complexity of managing HTML-code and, as a consequence, problems for front-end developers. This flaw was “fixed” with the help of .NET MVC, having transferred full control to the programmer, with all the ensuing consequences.
I suppose the outrage of the MVC evangelists, but nevertheless I will express my conviction: MVC on the web is like a saddle on a cow. Of course, this is not about the general idea of ​​separating code, representation and data. It's about the typical implementation of the pattern in the web - controllers, actions and the whole architecture itself.
In general, the MVC pattern was coined for the desktop, and there it did not replace the components, but was used to build the application architecture.
One of the significant problems of MVC, as well as other non-component solutions, is the lack of ensuring the persistence (state of the elements) of a page between calls from the browser. In the good old WebForms, we set the form, for example, the checkbox and did not worry about how it will be drawn and how its state will be restored after a reboot. That is, the programmer did what he was supposed to do - the implementation of business logic, interacting with components through their backends, and processing events of page elements after user actions. Essentially the same as in the desktop.
MVC frameworks do not provide this automatically; therefore, the state of the page must be restored manually, and on complex pages (for example, a catalog with a basket, product selection filters, etc.) this task is not trivial.
The simplest example to demonstrate the seemingly contrived problem with persistence. A certain page with tabular data. At the top of the page is a filter form, for example, a date range and a Search button. Push the button. The action with parameters is called, the model is loaded, displayed on the page. Fine. Next - click, for example, on the link paginator or column header to sort. The corresponding action is called with the parameters ... oh, where is our date range? Go back, write it in the session (hang all the elements on the link paginator, etc.). And this is just a simple, albeit everyday, example. Separate problem of complex presentation pages: one huge with a huge controller and model, or a partition into modules, widgets, and how then to combine all this?
There are different ways to solve problems. For example:
- large models that include the whole page, which is absurd, because the model is, first of all, a business data model, and not a dump with page data;
- all sorts of hierarchical MVC type small MVC in one large. Even comment on this nightmare is not worth it;
- ViewState as in WebForms - this is still all right, but there are its own, more than once described, problems;
- asynchronous calls to the server without reloading pages up to the so-called SPA pages.
The latter option is much more laborious in development, but, nevertheless, has become very popular, although there is not the slightest reason for this. The truth of life is that the user doesn’t care how much it loads. Moreover: the user is usually annoyed that the type page has loaded, but something is not yet loaded there and it is not clear when and how it will be loaded. Plus browser brakes, especially when using client javascript frameworks, and especially on mobile devices. Of course, such problems mostly torment developers in all sorts of Silicon Valleys. For our users, the user or customer is a valenok, who himself does not understand what he wants, and our task is not to do as he requires, but to explain to him that he actually needs something completely different (as a rule, what we already know how to write). And he doubts - let him google that this season the angulyar and all kinds of reactants are the last beep, the trend and in general.
But then the question arises: for whom smart people have come up with cloud computing, if some push the logic onto the client (the argument in the form of saving tens of kilobytes at the current Internet speeds and cheap money is not convincing)?
In fact, these torments (or rather, perversions) are done only for one reason - to circumvent the problem of persistence of page elements. That is, they invented a crutch in the form of MVC, then instead of curing the limbs and abandoning the crutch, they simply added one more pair to it - client javascript frameworks.
Of course, there are sites like social networks or google where, as the main functionality, we need asynchronous data exchange, messaging and all sorts of notifications, but the percentage of such sites among the entire set of these is approximately the percentage of zakerbergs among all programmers.
What, in my humble opinion, should be done: take a component solution and solve the problem of managing HTML code without complicating the work of the programmer. Attempts of similar decisions are on other platforms. For example, the PHP framework Prado, but there the developers stepped on another rake - they began to create all sorts of custom tags for the front end, all sorts, and others like them. However, Razor with its “bird’s” language also does not delight the web designers.
An example of the solution we need is the Java Wicket framework, on the basis of which the Zippy PHP framework was made. In fact, the main architectural solutions were ported. In particular, pure HTML is used as the front-end and, of course, event-oriented component architecture.
We will not dwell on Zippy - the project has a home page and a repository on GitHub. Therefore, we return to what we started from - an alternative to existing solutions for .NET - the ZippyNet framework, as a result of porting from PHP (Wicket) to .NET.
The framework does not require either WebForms or .NET MVC libraries. Sources on github . In addition, the project includes a simple website preparation to demonstrate the configuration and operation of the framework and a page with some elements, as an example of use.
In short, the principle of operation.
Front end:
<a zippy="link1">click me</a> <span zippy="label1" ></span> Back end:
namespace TestApp.Pages { public class MainPage : ZippyNet.Html.WebPage { public MainPage () { Label label1 = new Label("label1", "Hello"); ClickLink link1 = new ClickLink("link1"); // link1.setClickHandler((HtmlComponent sender) => { label1.setText("I am clicked"); }); // . this.add(link1); this.add(label1); } } } How it works.
The back-end and front-end are associated with the identifiers label1 , link1 in the special attribute zippy . Passive templating is used. When rendering a page, an instance of the class of the corresponding component finds its tag in the DOM model (the CsQuery library is used) and changes its value or attributes in accordance with its data. At the same time, for event source elements, a special type of HTTP request addresses is formed, according to which the server understands which element was clicked or switched, that is, is the event source (when you first access the page, when an instance of its class is created, the URI contains the class name pages). And at the same time, no ViewState is needed - an instance of the page class with child components and, accordingly, their data is stored in the server session.
And by the way, about AJAX. Despite the fact that the need for asynchronous calls when using this framework is no longer necessary, nevertheless a number of components support asynchronous operation for those cases when it is necessary. Moreover, asynchronous work is provided by the same component approach. The developer does not need to program anything, much less stick everything, forgive, Lord, Angulyars and reactants.
All you need to do is replace the handler with setAjaxClickHandler. The link1 component when rendering a page template on the server will add an onclick handler with an AJAX request. When rendering an asynchronous response, the label1 component will respond with a javascript that changes its text value on the client with new text (something like $ ('# label1'). Text ('I am AJAX clicked')), which will be performed using eval (). You do not need to encode anything else.
It should be noted that AJAX requests, like regular synchronous, are executed in the context of the page instance (with access to the state of all page elements and their data) - unlike the MVC controller that is re-created each time.
This is the essence of the components - they themselves ensure the preservation of their state, interface rendering and event handling, depending on the context. The programmer focuses on business logic and the coder works with pure HTML. The components ensure the modularity of the project and, as a result, the scalability of the development. Components are easily extended by simple inheritance from the corresponding class with overloading of the necessary methods. For example, the date input component inherits the functionality of the text input element (for the tag), but when rendering it additionally generates a javascript line that assigns the tag to the DatePicker plugin from the jQuery UI. And when processing a request from the server, it converts the received values ​​into DataTime.
At first glance, the article - PR some kind of knee crafts, but this does not make much sense. Unlike most “cyclists”, I am a realist and I know that I will use my bicycles only - I wrote them for the implementation of my projects, which give me a piece of bread, much faster and easier.
But I would like to draw the attention of the community, especially newcomers, who are convinced that PLO and MVC are one and the same, that despite the presence of hot-air fashionable chips and all sorts of “trends”, there are often much simpler logical and natural solutions and it is not always worth running as a herd of lemmings just because this direction is indicated by some programming gurus or because Google is promoting the next JavaScript framework.
Source: https://habr.com/ru/post/268229/
All Articles