© 2006-2008 Radicore Software Ltd
Latest news
RADICORE v1.38.0 released01 August 2008
RADICORE v1.37.0 released01 July 2008
RADICORE v1.36.0 released01 May 2008
Knowledge Base
The use of Cascading Style Sheets within Radicore22 April 2008
How to implement Two Factor Authentication01 February 2008
How to implement a Virtual Private Database01 October 2007
Articles
Creating an Oracle driver for RADICORE15 January 2007
Working with a stateless protocol10 March 2006
Performing client-side XSL transformations11 December 2005
Other Stuff
Object Relational Mappers are EVIL20 August 2007
What is OOP?03 December 2006
Stored Procedures are EVIL03 September 2006
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:
- Data Access Object (DAO). There is a separate class for each different database engine (MySQL, PostgreSQL, Oracle, etc) which contains all the code necessary to communicate with that RDBMS. This component will construct all SQL queries based on the information which is passed down to it from the business layer component.
- Abstract Table class. This forms part of the Model in MVC. This contains all the code necessary to read from and write to any database table, plus performing any primary data validation which verifies that all user input conforms to each field's data type. It is called an "abstract" class as it cannot be used on its own - it must be extended into a "concrete" database table class.
- Page Controller. There is a separate page controller for each Transaction Pattern. This deals with all GET and POST requests, communicates with the Model, then passes the results to the View where the data is extracted into an XML document before being transformed into HTML by an XSL stylesheet.
- XSL stylesheet. This forms part of the View in MVC. There is a separate stylesheet for each Transaction Pattern which transforms the XML document into HTML. Each stylesheet is broken down into a series of zones which are filled using data extracted from the XML document. Certain zones, such as the menu bar, navigation bar, action bar, pagination area and scrolling areas, are automatically handled by standard code. Each page has one or more zones for application data which are filled using data provided by different Model components.
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.

