© 2006-2024 Radicore Software Ltd
Latest news
RADICORE v2.30.0 released14 November 2024
RADICORE v2.29.0 released27 July 2024
RADICORE v2.28.1 patch released11 May 2024
Knowledge Base
Evolution of the RADICORE framework01 June 2022
How Radicore prevents SQL Injection attacks17 July 2021
How Radicore prevents CSRF attacks08 October 2017
Articles
Global Awards Winner 2023/2428 July 2024
Support for PHP4 dropped, support for PHP7 started01 October 2016
Why you should build your web application back-to-front06 January 2013
Other Stuff
The true purpose of Dependency Injection28 November 2024
DTOs are Diabolical24 November 2024
RE: Back to Basics - Three or Four OOP Pillars?20 November 2024
Videos
Global Awards Winner 2023/2428 July 2024
What are Transaction Patterns and how are they used in the RADICORE framework?16 May 2024
An overview of the Role Based Access Control (RBAC) system within RADICORE07 December 2022
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, SQL Server, 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, quicksearch 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 by inserting the relevant code into the Model component.