Let front-ends handle views.
This is the time we break up MVC and make it more practical. We are going to focus on back-end without view concerns. There are deeper issues regarding the broader concerns of the model, view and controller. The three-point idea cannot be so simple. The reality is more complicated. Now without view, we are going to slice model and controller into smaller applicable concerns. Views should not be handled from the back-end. We are threshing the view concern from the back-end altogether.
First of all, look at the plethora of front-end frameworks concerning views. Why do model and controller not catching up? Because model and controller are invisible to the naked eyes. Because users can decide on the looks and feels of an application. Because users have no idea and do not care on how data are being handled. Thus, due to the absence of users at the back-end, there is no pressure at all for developers to really pursue on improving model and controller.
The model-action framework is not a deviation from MVC. It is focusing on a set of concerns within MVC more thoroughly, specifically regarding the model and partially on the controller. A model cannot simply be an object as in the object-relational mapping (ORM). Object and model are two different things. A model is more abstract and semantic such as a user, a permission, a shop, a product, a cart, etc. It is never a good idea to simply wrap a model into a programming object. In fact, from the relational database theory, ORM itself is a bad idea. ORM is a quick and dirty database work that most front-end users do not understand and do not care. Unfortunately, we can still live with ORM as long as it works.
Whenever we use an application we always act on a model or more. I.e., user signs-in, shop shows offerings, cart checkouts, etc. Hence, there is a model-action pattern. Both model and action are abstract. They need to be mapped into the actual programming codes. We can make coding simpler when we slice them into model-actions. Always work on a model-action concern at a time. Two different model-actions are two different concerns.
A model can be sliced into many unique concerns where each is representing a unique action. I.e. user signs-up, user signs-in, user signs-out, user cancels, user changes-password, user changes-profile, etc. Every model-action needs a controller. The model-action framework involves controller. A controller is mapping an abstract model-action into a programmable expectation. How the controller handles it is a different concern. The controller may work with ORM, relational database, or nosql. The controller may work with complex algorithm or AI. The controller may look up somewhere else on the Internet. However, the result from a controller must satisfy the model-action concern. Similarly upstreaming, a model-action is satisfying the view concern from the front-end. Unfortunately, all existing back-end MVC frameworks are handling it in a very awkward way.
In the model-action framework, controllers satisfy the actions of models. An individual controller scope is kept small but not necessarily simple. However, there is a preset-controller-toll pattern which slices controller concerns into even smaller generalized cross-cutting concerns. A preset is a piece of code that run before and across controllers. A preset slices out some general concerns across controllers. There can be a chain of presets where each is handling a smaller unique generalized concerns across controllers. Some uses for presets are access control and logging. And a toll is a piece of code that run after and across controllers. A toll behaves almost similarly to a preset but on a totally different set of cross-cutting concerns. Some uses for tolls are watchdogs and filters. A controller is sandwiched between presets and tolls, where the controller delegates generalized concerns to them. Hence, the individual controller concerns becomes smaller.
The model-action framework and the preset-controller-toll pattern are not just theories. Harubi implements them.
This is the time we break up MVC and make it more practical. We are going to focus on back-end without view concerns. There are deeper issues regarding the broader concerns of the model, view and controller. The three-point idea cannot be so simple. The reality is more complicated. Now without view, we are going to slice model and controller into smaller applicable concerns. Views should not be handled from the back-end. We are threshing the view concern from the back-end altogether.
First of all, look at the plethora of front-end frameworks concerning views. Why do model and controller not catching up? Because model and controller are invisible to the naked eyes. Because users can decide on the looks and feels of an application. Because users have no idea and do not care on how data are being handled. Thus, due to the absence of users at the back-end, there is no pressure at all for developers to really pursue on improving model and controller.
The model-action framework is not a deviation from MVC. It is focusing on a set of concerns within MVC more thoroughly, specifically regarding the model and partially on the controller. A model cannot simply be an object as in the object-relational mapping (ORM). Object and model are two different things. A model is more abstract and semantic such as a user, a permission, a shop, a product, a cart, etc. It is never a good idea to simply wrap a model into a programming object. In fact, from the relational database theory, ORM itself is a bad idea. ORM is a quick and dirty database work that most front-end users do not understand and do not care. Unfortunately, we can still live with ORM as long as it works.
Whenever we use an application we always act on a model or more. I.e., user signs-in, shop shows offerings, cart checkouts, etc. Hence, there is a model-action pattern. Both model and action are abstract. They need to be mapped into the actual programming codes. We can make coding simpler when we slice them into model-actions. Always work on a model-action concern at a time. Two different model-actions are two different concerns.
A model can be sliced into many unique concerns where each is representing a unique action. I.e. user signs-up, user signs-in, user signs-out, user cancels, user changes-password, user changes-profile, etc. Every model-action needs a controller. The model-action framework involves controller. A controller is mapping an abstract model-action into a programmable expectation. How the controller handles it is a different concern. The controller may work with ORM, relational database, or nosql. The controller may work with complex algorithm or AI. The controller may look up somewhere else on the Internet. However, the result from a controller must satisfy the model-action concern. Similarly upstreaming, a model-action is satisfying the view concern from the front-end. Unfortunately, all existing back-end MVC frameworks are handling it in a very awkward way.
In the model-action framework, controllers satisfy the actions of models. An individual controller scope is kept small but not necessarily simple. However, there is a preset-controller-toll pattern which slices controller concerns into even smaller generalized cross-cutting concerns. A preset is a piece of code that run before and across controllers. A preset slices out some general concerns across controllers. There can be a chain of presets where each is handling a smaller unique generalized concerns across controllers. Some uses for presets are access control and logging. And a toll is a piece of code that run after and across controllers. A toll behaves almost similarly to a preset but on a totally different set of cross-cutting concerns. Some uses for tolls are watchdogs and filters. A controller is sandwiched between presets and tolls, where the controller delegates generalized concerns to them. Hence, the individual controller concerns becomes smaller.
The model-action framework and the preset-controller-toll pattern are not just theories. Harubi implements them.
Comments
Post a Comment