What architecture does RADICORE use?

RADICORE is constructed using a combination of the 3-Tier Architecture and the Model-View-Controller design pattern, as shown in the following diagram:

RADICORE architectural overview


Some modules come pre-written and are re-usable, while others need to be created for each application object. The following components are pre-written and re-usable:

The following components need to be created for each application object:

  • Database Table class. There is a separate class for each table in the application database. The initial class can be constructed automatically by importing the database structure into the data dictionary, then exporting it to the application, one table at a time. These details include the following:
    • Database name and table name.
    • Array of field names and field specifications.
    • Primary key details and optional Candidate key details.
    • Relationship details (parents and children).

    Note that the same table class can be used by any number of different components. The initial class contains all the code necessary to perform basic CRUD operations on that table, including primary data validation. Additional validation can be included by modifying the relevant customisable methods. Once created the table class will not be overwritten by the data dictionary export function so that any customisation will be preserved.

  • Screen Structure. Application data is extracted from each Model object and transferred to an XML document where the database table names and field names are preserved. The screen structure file identifies which table goes into which XSL zone, and for each zone which fields need to be displayed and in which order. Note that the same "detail" view can be shared by the Create, Read, Update, Delete and Search component for each database table. The screen structure is identical, it is only he behaviour which is different.
  • Component definition. This is a very simple script which identifies which Model, View and Controller is to be used for that component.

This architecture was specifically designed so that most of the developer effort can be concentrated on writing the business rules in the Model component, with very little being required for the View and Controller. No HTML needs to be written, but application pages can be customised through the use of CSS files. No SQL needs to be written, although there are provisions for customising the SQL queries which are generated by the framework by inserting the relevant code into the Model component.