Skip to main content

Separation of Front-end and Back-end Concerns

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.

Comments

Popular posts from this blog

Setting Up PyScripter for Quantum GIS

PyScripter is a general purpose Python Integrated Development Environment (IDE). Quantum GIS (QGIS) is a desktop GIS application that can be extended with Python plugins. Both are open source softwares. We intend to use PyScripter as an IDE to build QGIS Python plugin. We are using PyScripter 2.4.1.0 and QGIS 1.6.0 in Windows. PyScripter does not come with Python. On the other hand, QGIS is built in with Python. Thus, we will setup up PyScripter to use the build in Python in QGIS. We assume both PyScripter and QGIS are already installed. Preparing PyScripter batch file We assume that QGIS is installed in C:\OSGeo4W\ folder and PyScripter is installed in C:\Program Files\PyScripter\ . 1. Copy qgis.bat in C:\OSGeo4W\ bin to pyscripter.bat 2. Edit pyscripter.bat to remove the last line that read something like this start "Quantum GIS" /B "%OSGEO4W_ROOT%"\apps\qgis\bin\qgis.exe %* and replace it with this in one line Start "PyScripter" /B "C:\Progr...

Using React in Foundation for Sites

This post was the precursor to the Foundation-React Template . React and Foundation are two different web UI frameworks addressing different needs. They evolve differently. Both of them are powerful on their own accord. Fusing them together may create superpower. We will walk through the process of adding React into Foundation. We will start by installing both Foundation and React through command line interface (CLI). Then we will create a simple Todo web app. Along the way we will highlight the development process. But before all that, let us summarize React and Foundation. The details can be found at their respective websites. Both of them are well documented. React is a run-time UI rendering engine. It renders dynamic UI elements in its own fast virtual DOM, and only update necessary changes to the slow browser DOM. This behaves like a  double buffering DOM which makes any UI update feels fast. React wraps a UI rendering script in a component. A React component can ...

Debugging PHP using Apache Error Log

PHP runs on the server side and behaves like a function that return a value against the given arguments. A remote client may call this function and expect a specified return value and nothing else. So how do we debug this function ? It must not return debugging messages since the client is never designed to handle them. We must never burden any client to handle debugging messages. If we run PHP through Apache server then we can use the error log to keep our debugging messages. It may not be the best way to do it. But we only want to talk about this approach now. Error Logs The Apache error log files generally can be found in the following directory: var/log/apache2 We issue the following command from within the directory to read the latest error messages: # tail error.log The tail command reads the last few lines from the error.log file and prints them on the terminal. If we need to read a specific number of lines from the end of the file then we can specify the -n opti...