Separation of concerns is the cornerstone of MVC framework. Model, view and controller are three broad concerns of web-based software development. On its early days MVC was implemented on server side. The server renders views for clients. Nowadays, most clients render views themselves. Even the terminology of client-server has already morphed into front-end and back-end. The need for back-end to handle views is diminishing. View concerns have became increasingly complex with two big sub-concerns of aesthetic and dynamics. Front-end evolves into bigger MVC concerns of itself. While back-end evolves into larger modeling concerns. Now, front-end and back-end are two separate concerns. Front-end and back-end are handled by two different teams of software developers with different specialties.
Back-end evolves into something like "dinner can be served even without plates, forks and spoons, without table and chairs, and without a dinning room." Front-end is serving the withouts.
Software modeling needs to be refactored. So far, modeling is developer-centric. A software is developed for users. User interface (UI) is extended with user experience (UX). Front-end is serving users directly. Back-end is also serving users like "what is it for dinner?" Modeling has to be user-centric.
I wrote a blog post Model-Action Framework which is describing harubi. I found most back-end frameworks bloated. So, I coded harubi with the intention to remove the view concern from MVC. However, I found most user concerns were embedded in views. So, I refactored model to include user concerns. Model should not be enclaved within the object orientation realm which favors developers. User understands model differently. User wants to act and react on software according to her needs. User acts on models. The model-action pattern slices model concerns into manageable pieces which are actionable by both users and developers.
Back to MVC, it is all about separation of concerns. User concern has grown up with complexity. MVC has to evolve too. Front-end and back-end have already being separated for different concerns. User-centric modeling should bind them all.
Back-end evolves into something like "dinner can be served even without plates, forks and spoons, without table and chairs, and without a dinning room." Front-end is serving the withouts.
Software modeling needs to be refactored. So far, modeling is developer-centric. A software is developed for users. User interface (UI) is extended with user experience (UX). Front-end is serving users directly. Back-end is also serving users like "what is it for dinner?" Modeling has to be user-centric.
I wrote a blog post Model-Action Framework which is describing harubi. I found most back-end frameworks bloated. So, I coded harubi with the intention to remove the view concern from MVC. However, I found most user concerns were embedded in views. So, I refactored model to include user concerns. Model should not be enclaved within the object orientation realm which favors developers. User understands model differently. User wants to act and react on software according to her needs. User acts on models. The model-action pattern slices model concerns into manageable pieces which are actionable by both users and developers.
Back to MVC, it is all about separation of concerns. User concern has grown up with complexity. MVC has to evolve too. Front-end and back-end have already being separated for different concerns. User-centric modeling should bind them all.
Comments
Post a Comment