リファレンス(仕様詳細) » Architecture Overview

Architecture Overview

Last modified by kashi on 2015/02/02, 10:21


hifive uses MVC architecture, illustrated here :


In Hifive we divide the client's components broadly into the following three layer

  • View : Creation of view screen (in HTML)
  • Controller : DOM manipulation, event handling, calling the logic layer
  • Logic : Data transmission, database processing, calculation

Each layer is responsible for a specific kind of processing.

As a result of this division, you get two benefits. One is the increased productivity. Because the definitions file and structure of each process will be standardized, there will be no need to worry about how or where to write code. Another benefit, especially for large teams of developers working on one project, is that the code becomes much more easily maintainable and readable. Because of the standardized structure, you can easily understand the code when you do typically complicated tasks such as transferring a project to another member or team, reviewing code written by somebody else or maintaining the source code. 

In each layer there is a lot of common and useful functionality that is automatically included at runtime, for example:

  • View template engine
  • UI block
  • Library for asynchronous processing

This reduces the amount of separate declarations and allows for cleaner code.

The main design components in version 1.1 (current) and their roles are outlined below.


The controller is mainly responsible for event handling and view management. It can be declared hierarchically. By dividing a screen into its separate functions and assigning a controller to deal with each, the duty of each controller becomes more clear and the code is easier to divide into smaller blocks. Because of this, parallel development becomes easier for large groups and areas needing to be changed during project maintenance become clearer.

One of the characteristics of the Hifive controller is that  it can be defined hierarchically  .
By assigning a separate controller for each function the code required for each controller is lessened and maintainability is improved. It is also possible to  divide the screen into a number of different spheres and give a separate controller responsibility for each. As a result, access to, or event handling of, elements outside of the controller range is avoided. Even with a complicated screen containing multiple controllers, unplanned actions can be prevented.


Views are written in HTML and CSS. On-screen contents will be updated by explicit operations from the controller or by the data binding mechanism (which we will talk about later).

With Hifive, we offer the following three types of view management:

  • jQuery (general DOM manipulation)
    • Used when manipulating a specific element (or group of elements).
      By using the controller's $find() method it can acquire any jQuery object that descends from  the element in the controller’s bind  and that matches the given selector.

 This system differs from using jQuery directly; the controller's zone of influence is limited to only  descendants of the controller's binded element  and hence there is no risk of accidentally manipulating elements outside of the controllers range.

  • Template Engine
    • This is used when the view will contain complicated tag structures. The tag structure generated when using jQuery alone can be difficult to understand. If the view is generated from somewhere in the business logic code, it will be difficult to know from where exactly the view is being manipulated and to recognize clearly the zone of influence when you want to do maintenance.

However, if the view creation is left to the template engine, tag structure will be easy to understand and it will be clear where and what must be altered to update or change the code. With Hifive we use  EJS, a template engine that allows JSP-like coding.

  • Data Binding (Introduced in ver.1.1)
    • Data binding is an arrangement that should be considered for views that will be frequently updated.
      In this system, you must describe the relation "The value for on-screen element X is linked to property Z for data object Y" in the view. Then when the DataItem (each representing a record in the data model) and the ObservableItem (the temporary form of the DataItem) are changed, their change events are detected and the linked view is automatically updated.

Because data changes are automatically reflected on screen the developer doesn't have to worry about DOM manipulation with jQuery. The developer can then concentrate on the data processing side and view and logic can be clearly separated.
Another feature of data binding is that changes to one data object can be reflected simultaneously in multiple elements. Thanks to this, keeping multiple on-screen components in a consistent state becomes much simpler.


In Hifive we interpret logic to mean "processing", for example:

  • Complicated processing
  • Communication with the server
  • Local Database processing

(View manipulation or event handling are not dealt with)

By being careful to only include "processing" code we can expect the following merits:

  • Improved readability -> It becomes easier to trace processing
  • Improved re-usability -> No need be concerned with view output
  • Easier testing -> By using the unit testing tool it becomes easier to run tests
  • Improved maintainability -> There is no need deal directly with the JavaScript used when changing appearance
                                                When making amendments to the logic you shouldn't have to worry about how the view is implemented (HTML structure etc.)

The logic layer defines processing, communication with the server and so on.
This layer is especially useful for defining processing that is common to multiple screens (controllers). By using JavaScript at browser runtime it is possible to manipulate the view from the logic layer, but by taking care not to include any direct view manipulation it will be *easier to reuse the code and do unit testing.

Applications using HTML5 rely on a variety of client APIs, so, depending on the application, sufficient unit testing will be demanded by the client. With this in mind, we recommend keeping all your complex logic code separate to make testing simpler.

Data Model

The data model is the layer responsible for data control. By passing a schema to the data model, it can check validity of, and impose restrictions on, data. JavaScript allows you to set any arbitrary key value pair. However, without limitations on object properties it can become difficult to spot bugs if the data structure changes during programming or after maintenance.

The Hifive data model uses a predefined schema for each model, similar to many DBMS.
By doing this, the values of the object (which represents a record in the RDBMS) can be accessed using the get() and set() methods. If any keys which are not defined in the schema are assigned, an error will be thrown. The schema is not just for defining the type of variables, but also putting limitations on them, for example "only values from 1-10" or "not an empty string".

Also, the model allows for declaring the dependent calculation property. For example, if property X is given the "dependent calculation on S" property, when S changes a function to automatically recalculate X will be called. The value returned from that function will be newly assigned to X and saved by the framework until S is reassigned a new value.

Using ECMAScript5 the property getter and setter functions can now be defined. However, this feature is unfortunately not supported in Internet Explorer (IE) 8 and IE versions older than IE8. Taking into consideration that IE8 will likely continued to be used (whether we like it or not) in systems requiring a wide reach, such as B2C and enterprise systems, we decided to use the method base system.

Furthermore, the data model in hifive includes a mechanism for alerting the exterior of data object additions, deletions or changes. One of hifive's three view types, the data binding mechanism, supports this functionality; by simply altering the data model any changes will be reflected on screen. The full power of this is most apparent in tasks such as displaying repetitive data (e.g. lists) and the developer can focus on writing code.

AOP for Controller / Logic

The controller and logic layers of Hifive adopt the aspect-oriented programming (AOP) paradigm. To be more specific, it is possible to set up an interceptor (method hook) before calling any of the controller / logic methods. It is thereby possibly to start any event handler logging or execution timing code in just one place. 

Unfortunately performance related problems are often realized during the middle or final stages of development, and we're prone to just sticking something like :

var start = new Date();


var end = new Date();

alert(end - start);

inside a function that seems problematic.

In situations such as this, by using AOP you can measure execution time without having to rewrite the code.

Recent browsers include a high level profiler (such as Developer Tools in Chrome or Firebug in Firefox). By using these you can measure execution time in detail. However, because the level of measurement detail is defined by the browser, it can sometimes be too detailed (like the level of the browser's native API) and the load of the profiler itself can become a problem. In such cases you can measure event handler processing at a consistent level using AOP.

Copyright (C) 2012-2017 NS Solutions Corporation, All Rights Reserved.