Three approaches to the methodology of building a complex client application
Probably, there is no single recipe that would suit everyone. This concerns any problem. For developers, this thesis is self-evident, and the involvement in the use and design of individual tools is determined mainly by professionalism. The invention of bikes is romantic and inevitable.
Particularly likely is the invention of the bicycle, when the growth of application complexity occurs gradually and in a certain sense imperceptibly. A complex application is usually a rich application (rich), its elements and features are specified by the W3C www.w3.org/TR/backplane . The well-known JavaScript evangelist Addy Osmani additionally defines a complex application: “In my opinion, a large JavaScript application is a non-trivial application that requires considerable developer effort to support, with the most complex handling of processing and displaying data on the browser” (http: // addyosmani. com / largescalejavascript /).
For desktop applications, the development process seems to be established, described. For network applications, the overall scheme is also clear. But the technical feature of the web, expressed in a markup language and a non-formalized concept of usability, complicates the understanding and description of rich applications. The peculiarity of the network nature of the application, in which the ability to work in real time is limited by technical factors and there is no instant access to data; feature of the object language JavaScript, which has no native constructs for classes; the particularity of deployment and execution in different environments (i.e. browsers), which affects performance and capabilities, all these factors apparently prevented in the early days to determine the power of client applications and develop a common design for their design (litter for pathos).
')
I just do not see such a common, even if it is. Instead, I see and interpret several different concepts. The first is the famous MVC (Model View Controller) design scheme. The second is the concept of logical separation of the code from Nicholas Zakas (address at the Yahoo conference www.youtube.com/watch?v=vXjVFPosQHw ).
The third is the naive approach to creating code, where data is mixed, operating with interface elements and various functions (mixing can tragically turn into “macaroni”).
At the same time, the question, what is in these approaches is the organization of the code, and what is the organization of the functional, is a rather thin line.
The MVC (Model Representation Controller) scheme has found several successful JavaScript implementations: backbone.js, JavaScriptMVC. Briefly about the scheme. The model contains data in their structure and hierarchy, the View describes the version of this data that is transmitted to the user. There is no direct connection between the Model and the View, for this there is an intermediary in the form of a Controller - it manages events and can manage several views or transfer control to another MVC module (in the hierarchical MVC scheme).
The control features of the controller led to a slightly different model MVP Model View Presenter, and then to MVVM (Model View ViewModel). MVVM is distinguished by more “close” connections between the Model and the View in the form of a View-Model (or a Visible Model, if you wish), which synchronizes data both at the event on the Model side and on the View side.
MVVM has been described for Silverlight and has advantages for complex interfaces with a certain logic that differs from the logic of the application (for example, when adding an object to a model, the interface of the application changes nontrivially). For HTML, the MVVM schema is especially good thanks to the DOM, which, as you know, can easily hold data. Therefore, MVVM was successfully implemented in the knockout.js framework. Initially, everything is simple. There is a data model provided by the server. There is a representation in the form of a DOM, in the form of a markup. And there is a View-Model, which describes a change in the view, connects the model and the view, and synchronizes this connection.
It should be noted that MVC can be interpreted simply as a separation of the three levels of the application, and in no way regulate the relations between them. Therefore, quite often there are diagrams in which the Model and the View are linked by arrows, although it is obvious that in this way the useful scalability properties are lost when using different Views and the hierarchy of the Controllers. Read more about this very clearly in the first lecture by Paul Hegarty on iOS application development www.stanford.edu/class/cs193p/cgi-bin/drupal/node/259 .
Nicholas Zakas presented his development proposals (they can be formalized in the pattern language in the article Addy Osmani addyosmani.com/largescalejavascript ). He decided, in fact, to move away from the general model and logic, and use the “divide and conquer” algorithm: the elements of the application are decorated with interface blocks, and each is implemented in its own module. These modules do not exchange with each other. They know only about the sandbox in which they are executed. The sandbox, in turn, deals with the core of the application, which starts the process and monitors the sequence of actions. The kernel itself is not the last in the chain (calls): below there are standard libraries for technical work with the environment, such as jQuery, along with the plugins. For modular applications, a specification specification for AMD modules (and an alternative CJS) has been created.
Let me offer myself a third option, coming from the same “separation” approach. We delimit objects (in a broad sense) into actors, functional and scenarios. Actors are parts of the application in their graphic interpretation. You can risk calling them widgets. The actors have information about themselves, so the data is placed in them. Functionals are lists of possible transformations of similar widgets, each functional can be tied to an actor. The call of these functionals occurs in the script. The script can be actor-dependent, it can be initializing. It simply lists the consecutive calls of functionals. It is clear that this is not the most optimal way in terms of scaling with the possible complication of the task. (But, in my opinion, this is the most obvious way to create a bicycle.)
Where is scalability achieved
As Zakas himself described, the great advantage of his architecture of large applications is that you can build on any of the standard jQuery libraries and change them without problems, slightly correcting the Application Core level. Easily add modules and turn them off.
In the MVVM model, I see a very tough “vertical”: changes in the interface make it necessary to describe all three components; although the elements already described can be changed without any problems. At the same time, the most scalable, most flexible part is the presentation level, when a complete redrawing of the interface graphics does not affect its logic.
In the naive approach, there is also a hard link that defines the mandatory description of all three objects of implementation. But the most flexible part seems to be the level of scenarios that can change very simply.
Where the main logic is written
[thanks to the commentators most of this block is fixed!]
In the Zakas model, business logic and UI is implemented in modules.
In MVC, the logic is embedded in the Model, it can also be placed in the Controller, but this is rightly criticized (see sources). In MVVM, on the contrary, the logic is placed in the “intermediate” layer of ViewModel.
In a naive approach, logic is broken down into scenarios, and UI into primitive functionals.
Is there a lot of service code, an estimate of the theoretical volume for the framework
In the Zakas model, the framework describes the service connections of the modules with the sandbox (“launch in environment”), and the kernel describing the main types of actions.
MVC assumes the description of the main classes for model and representation. Some functions of the controller must also be implemented in the framework (for example, synchronization for the MVVM model).
The naive approach should contain the implementation of the “assembly” of actors and functionals attached to them.
Ease of testing parts
The modularity approach perfectly perceives test scenarios - each part of the circuit can be tested separately and each module as well.
MVC can also be tested “in parts” by the level of interaction with the Controller, but this is more “hard” in terms of testing.
The naive approach is adapted to testing the functioning of individual widgets. Testing scripts can be more difficult due to their branching and fuzzy initial states for testing.
Is the code really re-useable?
The modularity approach creates highly scalable modular solutions (moreover, when AMD is used throughout the entire Internet, and not just the application). The code can then be applied by parts within another project to another main library (YUI, etc.).
MVC can be scaled only within its task, in case of modification and replacement of the View level.
The naive approach creates separate functionals that can be reused on various actors. You can build a hierarchy of actors. Scenarios are “disposable”.
I would like to deepen this superficial analysis. What moments did I reflect incorrectly? What methods have a broader description? I ask all commentators to share their experience using MVC, MVVM and modularity approaches!
UPD
mark_ablov suggested an obvious connection for me between the MVC approach and the modularity approach: modules can be implemented on MVC schemes, in particular. So, we can get the following diagram:
Sources
habrahabr.ru/blogs/webdev/117791
blog.rebeccamurphey.com/code-org-take-2-structuring-javascript-applic
addyosmani.com/largescalejavascript
nirajrules.wordpress.com/2009/07/18/mvc-vs-mvp-vs-mvvm
www.w3.org/TR/backplane
Alex MacCaw, JavaScript Web Applications. jQuery Developers' Guide to Moving State to the Client, 2011
www.youtube.com/watch?v=vXjVFPosQHw (video)
www.intuit.ru/department/internet/aspnetmvcframe/1 (video)
www.stanford.edu/class/cs193p/cgi-bin/drupal/node/259 (iTunes, video)
blog.astrumfutura.com/2008/12/the-m-in-mvc-why-models-are-misunderstood-and-unappappiated (php, criticism of fat controllers)
martinfowler.com/eaaDev/uiArchs.html
Particularly likely is the invention of the bicycle, when the growth of application complexity occurs gradually and in a certain sense imperceptibly. A complex application is usually a rich application (rich), its elements and features are specified by the W3C www.w3.org/TR/backplane . The well-known JavaScript evangelist Addy Osmani additionally defines a complex application: “In my opinion, a large JavaScript application is a non-trivial application that requires considerable developer effort to support, with the most complex handling of processing and displaying data on the browser” (http: // addyosmani. com / largescalejavascript /).
For desktop applications, the development process seems to be established, described. For network applications, the overall scheme is also clear. But the technical feature of the web, expressed in a markup language and a non-formalized concept of usability, complicates the understanding and description of rich applications. The peculiarity of the network nature of the application, in which the ability to work in real time is limited by technical factors and there is no instant access to data; feature of the object language JavaScript, which has no native constructs for classes; the particularity of deployment and execution in different environments (i.e. browsers), which affects performance and capabilities, all these factors apparently prevented in the early days to determine the power of client applications and develop a common design for their design (litter for pathos).
')
I just do not see such a common, even if it is. Instead, I see and interpret several different concepts. The first is the famous MVC (Model View Controller) design scheme. The second is the concept of logical separation of the code from Nicholas Zakas (address at the Yahoo conference www.youtube.com/watch?v=vXjVFPosQHw ).
The third is the naive approach to creating code, where data is mixed, operating with interface elements and various functions (mixing can tragically turn into “macaroni”).
At the same time, the question, what is in these approaches is the organization of the code, and what is the organization of the functional, is a rather thin line.
The MVC (Model Representation Controller) scheme has found several successful JavaScript implementations: backbone.js, JavaScriptMVC. Briefly about the scheme. The model contains data in their structure and hierarchy, the View describes the version of this data that is transmitted to the user. There is no direct connection between the Model and the View, for this there is an intermediary in the form of a Controller - it manages events and can manage several views or transfer control to another MVC module (in the hierarchical MVC scheme).
The control features of the controller led to a slightly different model MVP Model View Presenter, and then to MVVM (Model View ViewModel). MVVM is distinguished by more “close” connections between the Model and the View in the form of a View-Model (or a Visible Model, if you wish), which synchronizes data both at the event on the Model side and on the View side.
MVVM has been described for Silverlight and has advantages for complex interfaces with a certain logic that differs from the logic of the application (for example, when adding an object to a model, the interface of the application changes nontrivially). For HTML, the MVVM schema is especially good thanks to the DOM, which, as you know, can easily hold data. Therefore, MVVM was successfully implemented in the knockout.js framework. Initially, everything is simple. There is a data model provided by the server. There is a representation in the form of a DOM, in the form of a markup. And there is a View-Model, which describes a change in the view, connects the model and the view, and synchronizes this connection.
It should be noted that MVC can be interpreted simply as a separation of the three levels of the application, and in no way regulate the relations between them. Therefore, quite often there are diagrams in which the Model and the View are linked by arrows, although it is obvious that in this way the useful scalability properties are lost when using different Views and the hierarchy of the Controllers. Read more about this very clearly in the first lecture by Paul Hegarty on iOS application development www.stanford.edu/class/cs193p/cgi-bin/drupal/node/259 .
Nicholas Zakas presented his development proposals (they can be formalized in the pattern language in the article Addy Osmani addyosmani.com/largescalejavascript ). He decided, in fact, to move away from the general model and logic, and use the “divide and conquer” algorithm: the elements of the application are decorated with interface blocks, and each is implemented in its own module. These modules do not exchange with each other. They know only about the sandbox in which they are executed. The sandbox, in turn, deals with the core of the application, which starts the process and monitors the sequence of actions. The kernel itself is not the last in the chain (calls): below there are standard libraries for technical work with the environment, such as jQuery, along with the plugins. For modular applications, a specification specification for AMD modules (and an alternative CJS) has been created.
Let me offer myself a third option, coming from the same “separation” approach. We delimit objects (in a broad sense) into actors, functional and scenarios. Actors are parts of the application in their graphic interpretation. You can risk calling them widgets. The actors have information about themselves, so the data is placed in them. Functionals are lists of possible transformations of similar widgets, each functional can be tied to an actor. The call of these functionals occurs in the script. The script can be actor-dependent, it can be initializing. It simply lists the consecutive calls of functionals. It is clear that this is not the most optimal way in terms of scaling with the possible complication of the task. (But, in my opinion, this is the most obvious way to create a bicycle.)
Where is scalability achieved
As Zakas himself described, the great advantage of his architecture of large applications is that you can build on any of the standard jQuery libraries and change them without problems, slightly correcting the Application Core level. Easily add modules and turn them off.
In the MVVM model, I see a very tough “vertical”: changes in the interface make it necessary to describe all three components; although the elements already described can be changed without any problems. At the same time, the most scalable, most flexible part is the presentation level, when a complete redrawing of the interface graphics does not affect its logic.
In the naive approach, there is also a hard link that defines the mandatory description of all three objects of implementation. But the most flexible part seems to be the level of scenarios that can change very simply.
Where the main logic is written
[thanks to the commentators most of this block is fixed!]
In the Zakas model, business logic and UI is implemented in modules.
In MVC, the logic is embedded in the Model, it can also be placed in the Controller, but this is rightly criticized (see sources). In MVVM, on the contrary, the logic is placed in the “intermediate” layer of ViewModel.
In a naive approach, logic is broken down into scenarios, and UI into primitive functionals.
Is there a lot of service code, an estimate of the theoretical volume for the framework
In the Zakas model, the framework describes the service connections of the modules with the sandbox (“launch in environment”), and the kernel describing the main types of actions.
MVC assumes the description of the main classes for model and representation. Some functions of the controller must also be implemented in the framework (for example, synchronization for the MVVM model).
The naive approach should contain the implementation of the “assembly” of actors and functionals attached to them.
Ease of testing parts
The modularity approach perfectly perceives test scenarios - each part of the circuit can be tested separately and each module as well.
MVC can also be tested “in parts” by the level of interaction with the Controller, but this is more “hard” in terms of testing.
The naive approach is adapted to testing the functioning of individual widgets. Testing scripts can be more difficult due to their branching and fuzzy initial states for testing.
Is the code really re-useable?
The modularity approach creates highly scalable modular solutions (moreover, when AMD is used throughout the entire Internet, and not just the application). The code can then be applied by parts within another project to another main library (YUI, etc.).
MVC can be scaled only within its task, in case of modification and replacement of the View level.
The naive approach creates separate functionals that can be reused on various actors. You can build a hierarchy of actors. Scenarios are “disposable”.
I would like to deepen this superficial analysis. What moments did I reflect incorrectly? What methods have a broader description? I ask all commentators to share their experience using MVC, MVVM and modularity approaches!
UPD
mark_ablov suggested an obvious connection for me between the MVC approach and the modularity approach: modules can be implemented on MVC schemes, in particular. So, we can get the following diagram:
Sources
habrahabr.ru/blogs/webdev/117791
blog.rebeccamurphey.com/code-org-take-2-structuring-javascript-applic
addyosmani.com/largescalejavascript
nirajrules.wordpress.com/2009/07/18/mvc-vs-mvp-vs-mvvm
www.w3.org/TR/backplane
Alex MacCaw, JavaScript Web Applications. jQuery Developers' Guide to Moving State to the Client, 2011
www.youtube.com/watch?v=vXjVFPosQHw (video)
www.intuit.ru/department/internet/aspnetmvcframe/1 (video)
www.stanford.edu/class/cs193p/cgi-bin/drupal/node/259 (iTunes, video)
blog.astrumfutura.com/2008/12/the-m-in-mvc-why-models-are-misunderstood-and-unappappiated (php, criticism of fat controllers)
martinfowler.com/eaaDev/uiArchs.html
Source: https://habr.com/ru/post/136886/
All Articles