The application classes provide certain application functionality to your Iron Speed Designer-applications. The application classes include important user interface building blocks and database management features that are critical to secure, reliable systems, but can be cumbersome to build.
Iron Speed Designer saves you the time and distraction of re-creating these features for each application.
Database connection pooling. The application classes use the database connection pooling provided by ADO.NET to minimize the overhead burden from heavy transaction loads on your database. Applications built with Iron Speed Designer automatically use this connection pool, saving you the effort of building this functionality.
End-user session management. Iron Speed Designer includes session management that allows any number of simultaneous end-user sessions.
Data validation. Most of the data field validation methods are contained in the application classes.
Export wizards. The file export wizard is in the application classes.
The application classes extend the .NET Framework to support applications built with Iron Speed Designer. The application classes are provided in source code and compiled form by Iron Speed Designer. Applications built with Iron Speed Designer use classes inherited from other application classes and .NET Framework classes. Your application’s classes themselves inherit from the Microsoft .NET Framework classes.
Application classes are generally derived from .NET Framework classes. |
For example, the default page class used by .NET is System.Web.UI.Page. This class is sub-classed in the application classes as BasePage. Applications use this class for individual pages.
The purpose of the application classes is two-fold. First, the application classes provide extensions to the Microsoft .NET Framework to deliver additional functionality. Second, they enable you to add features that apply to the entire application by making changes to these classes.
This section documents the application classes and the methods that are the most likely candidates for making changes. The application classes may contain several additional classes and methods not documented here that provide additional internal support. We do not recommend changing any of the internal classes and methods.
In the Presentation Layer, Iron Speed Designer creates these class types:
Page. A code-behind class is created for each page in your application.
Many class hierarchies contain customizable classes that are created once and never overwritten. The customizable classes are usually the lowest level classes so you can override any class or method in your application’s class hierarchy. By adding your application-specific code to the customizable classes, you are free to extend or replace functionality without worrying about your extensions being overwritten by subsequent updates.
The Data Access Layer classes provide the infrastructure to handle data from a database. In the Data Access Layer, Iron Speed Designer creates these class types:
Record. A class corresponding to a record is created for each database table used in your application to perform record-based access (e.g., insert, update, delete). In general, the Record class corresponds to a single record or row in a table and the Record class contains all of the fields within the table and properties to get and set these fields. In effect, the Record class maps the table to an object. “Virtual record” classes are created for each database table and database view that are joined together.
Table. A class is created for each table and database view in your application to provide the methods necessary to retrieve a group of records based on your filtering criteria and end-user filtering criteria. This class contains methods to read and write data from the database. It is the primary workhorse class of the Data Access Layer. The GetRecord() and GetRecords() functions in the Table classes are the main methods used to retrieve data from the database. The Table class also contains properties to retrieve the actual names of fields in the table.
The Data Access Layer classes provide controls for columns, records, table utilities and tables (your application database schema). These controls work together to capture all the schema information needed to compose and display the different tables required by your application. These controls include the functions to display a list of record data inside a table or retrieve a record that includes specific field values.
The naming convention for the Record class is:
<TableName>Record
<ViewName>Record
<QueryName>Record
For example:
CustomersRecord (table name is "Customers")
vwEuropeanCustomersRecord (view name is "vwEuropeanCustomers")
qUSCustomersRecord (query name is "qUSCustomers")
The naming convention for the Table class is:
<TableName>Table
<ViewName>View
<QueryName>Query
For example:
CustomersTable (table name is "Customers")
vwEuropeanCustomersView (view name is "vwEuropeanCustomers")
qUSCustomersQuery (query name is "qUSCustomers")
Let’s say you want to write a function to get the full name of a customer and the database only contains the first name and the last name. This type of code customization is best created in the customizable class file for the <Table>Record class. On the other hand, if you want to add a customization that deals with a group of records such as getting the maximum number of records, or modifying the default filter or sort criteria for *all* access from this table, then you can customize the <Table>Table class.
Please note that if you modify the behavior of the <Table>Table class, you would modify the behavior for *all* access from your application. If you want to just do some specific modification for a single access, then you are better off doing that at your page level, and not modifying the underlying behavior of all calls to retrieve the data.
There are other helper classes such as <Table>SqlAccess and <Table>Definition.