Understanding the Aptify Generic Entity Architecture

Aptify Generic Entity (GE) architecture provides a standard, generic interface to relational data models, thereby simplifying programming, improving stability of systems, decreasing development time, and increasing the standard feature set for products developed using this architecture.

Historically, many database systems have been difficult to develop, costly to maintain, and lacking in features. One reason for these drawbacks is the direct access from the user interface to the database that is common in these applications. In most systems, developers of the user interface are responsible for understanding the schema in the relational data source, for accessing this data, and for using the appropriate coding techniques to ensure data integrity (for example, transactions and validation).

This methodology of system development has proven to be difficult for many reasons including:

  • Programming correctly requires systematic and consistent attention to error handling, data validation, and database transactions. Because most systems are built under severe time pressure, proper attention to these details is often the first thing to slip. Additionally, most systems are built with less than adequate time to test for these shortcomings.

  • Programming correctly requires significant understanding of many technologies, how they fit together, and their appropriate uses. While quite a few developers are capable of grasping all of these concepts, people are typically most efficient when dealing with a smaller set of the big picture. Additionally, some programming professionals are unable to understand the complex data models that exist in today's relational implementations.

  • Database level programming is relatively low-level. To simply update a record in a SQL Data source, a programmer must understand how to:
    • Obtain a connection to the database.
    • Notify the database system of the start of a transaction.
    • Prepare a relatively cryptic SQL statement, which can easily be flawed (because it is difficult to test all cases of a SQL statement for each update sequence).
    • Run the statement on the server using the appropriate options with the connection technology chosen (such as ADO, RDO, and ODBCDirect).
    • Notify the database of the completion of a transaction, or rollback if unsuccessful.
    • Close the connection to the database.

With this many steps at a high level, it is easy to see how the complexity of directly modifying the data in a relational source typically leads to largely untested and unsuitable code for critical systems.

Aptify's approach, which provides a generic, object-driven model to access any type of relational data, greatly simplifies the development of database systems. Additionally, this generic abstraction layer serves as a foundation for the development of other reliable and scalable generic system services. Programmers who understand the Generic Entity Architecture and its benefits can create and add new objects to Aptify to provide customized functionality.

This topic contains the following sub-topics that describe the high-level features of the GE architecture and provide information for developing against the GE object model.

About the Generic Entity Architecture Features

This topic provides an overview of the features of the Aptify Generic Entity (GE) architecture. These features are discussed in the following sections:

Provides Easy Access To Data

The GE architecture uses an object model that is based on objects and collections. For example, to access all of the fields in a record, a programmer uses the fields collection of the generic entity. Programmers with database experience are accustomed to this kind of process, but the process is also easy to learn for people without database experience.

Provides Validation

The GE provides validation for all standard field-level validation needs. The following validation rules apply:

  • Required fields may not be left blank
  • For numeric fields, a valid numeric value is required
  • For text fields, a valid text value is required (no use of the quoted identifier)
  • For date fields, a valid date value is required

While these rules are indeed quite simple, they provide the field-level validation that most database systems do not consistently implement. In many cases, additional validation code is required when the logic goes beyond the field level. Each object derivation from the GE may implement any combination of validation logic. See Developing Field-Level Validation Scripts for a discussion on specifying additional validation logic for a particular field.

Provides Abstract Data Model

By providing a powerful, abstract data model, the GE architecture enables the creation of tools that dynamically configure themselves around the structure of an object. For example, it is quite easy to create generic viewers, export tools, and merging tools that take advantage of the generic entity's object model.

Supports Complex Data Types

In most database systems, relations between data are highly abundant. In many cases, one-to-many relations exist that typically consist of foreign key links between tables. Typically, it is difficult to write code that will easily manipulate master/detail data relationships. The GE supports modelling complex one-to-many and many-to-many data relationships via extended object attributes called Sub-Types.

Sub-Types allow you to model data with the objects with any level of depth. Additionally, it is possible to have any number of sub-type collections at any given level of the data model. It is also possible to dynamically examine the capabilities of the object via a standard GE interface.

See Creating Sub-Type Entities for information on creating sub-type entities within Aptify.

Permits Overriding Standard Functionality

Although problems exist in the traditional database development methodology, framework-based development has not been very successful for several reasons. One of the most pressing reasons not to use a framework to develop database applications is that most frameworks limits developer flexibility. Additionally, most frameworks are design-time frameworks, not run-time frameworks, which causes additional loss of value.

In Aptify GE architecture, as with all Aptify technologies, it is possible to select the services your application requires. At any point, it is quite easy to augment, override, or use the capabilities of the GE. Because of this focus, it is always possible to go around the default functionality of the GE to accomplish a task. While the vast majority of requirements fall within what the GE can accomplish by itself, the need does arise to go around or augment its basic functionality.

In Aptify, a developer can create a plug-in to modify the standard behavior of an entity, including validation, duplicate checking, and merging operations. See Developing Entity Plug-in Objects for information on entity plug-in objects. See Developing Duplicate Check Objects for information on duplicate checking objects.

Provides Security

The GE architecture provides a standard security layer. Using the Generic Entity architecture automatically enables the configurability of each entity with separate permission control lists for CRUD (Create, Read, Update, and Delete) permissions. It is easy to add more security capabilities to GE derived objects, or to override the basic security capabilities if necessary.

Enables Rapid Development

By abstracting complex data models with a standard object interface and providing the necessary tools to build such objects quickly, the GE architecture helps to decrease overall development time while improving reliability and the feature set. One of the greatest benefits for system development efforts is that this architecture establishes a well-defined interface between each layer of the application architecture. As a result, a developer can become very efficient at developing GUIs without prior knowledge of the inner workings of the data model. In fact, the design goal of this object architecture was to enable business analysts to take a system directly from prototype to production (GUI level) with no understanding of the data model in its raw relational form (only an understanding of object fields, sub-types, and so forth). This encapsulation of system logic effectively allows for the separate encapsulation of knowledge of the database and the GUI, simplifying the overall development cycle.

Provides Automatic Version Control for Data

Another problem with many database systems is tracking and controlling changes to the data. As database systems are used, the value of the information contained within them grows. Due to this natural effect, it is important for an organization to be able to control and review changes made to the data. In most systems, data changes are difficult to control and difficult to track. In any GE based system, it is easy to control access to data, and to track changes to the data. Version Control (referred to as Record History within Aptify) is built into the GE, and any object built using the GE automatically receives this feature. It is a configurable option that an administrator can turn on or off for each entity. Because mass storage is available at low cost, version control is typically left on for most entities.

In addition to tracking changes, it is possible for the GE to require the user making the change to document the reason for the change (by entering comments, who requested the change, and so forth).

As the system records data changes, a user-oriented change string is recorded along with a snapshot of the object. The Change String is a message that states which fields were changed in a user-oriented syntax. An example is shown below:

First Name changed from Bob to John

Last Name changed from Jones to Smith

Title changed from President to CEO

Company changed from ABM Corp. to SOL Corp.

The snapshot of the object is required in an XML style markup language. An example is shown below:

Version 2 of the record

       <FIELD NAME=FirstName>John</FIELD>
       <FIELD NAME=LastName>Smith</FIELD>
       <FIELD NAME=Title>CEO</FIELD>
       <FIELD NAME=Company>SOL Corp.</FIELD>

Version 1 of the record

       <FIELD NAME=FirstName>Bob</FIELD>
       <FIELD NAME=LastName>Jones</FIELD>
       <FIELD NAME=Title>President</FIELD>
       <FIELD NAME=Company>ABM Corp.</FIELD>


The syntax of this language is designed to accommodate nearly any type of data format. Due to its highly structured format, it is possible for the Generic Entity layer to restore prior versions automatically to perform difference analysis and to do merging.

Provides Duplication Check Object

The GE defines a hook in the system to allow each customer to define the logic for checking for duplication of data. For example, depending on the locale, the customer, and a number of other factors, customers may often have companies entered into the system that are really duplicates. The GE defines a standard interface that can be used to define a duplication object which determines whether a record about to be created would potentially (or absolutely) be a duplicate of any other record. The two levels are defined as follows:

  1. Absolute duplicates: If the duplication check object finds what it considers to be an absolute match (for example, a company record that has ALL relevant fields matching: name, address, phone, city, state, and so forth), the GE does not allow the record to be created.

  2. Potential duplicates: If the duplication object finds what it considers to be a potential match, but is not absolutely certain that it is indeed a match, the system prompts the user stating that it has found x potential duplicate(s) and allows the user to view them.

Each duplication object simply defines the logic and returns to the GE a listing of absolute and/or potential duplicates. The GE in turn provides the GUI and decision logic required for the end-user, thus standardizing the GUI and simplifying the programming to implement this feature. See Developing Duplicate Check Objects for information on duplicate checking objects.

Provides Customer-Extensible Logic System

The GE architecture provides a hook into the logic of the creating and updating of records in the database called a verify object. This object is an optional, customer-defined object that hooks into the Save process of the GE for a given object type. For example, a customer may want to add logic to send an e-mail to a specific user whenever a new order is placed. We could easily build an object to comply with the requirements for the Verify Object interface and perform its custom operations. By supporting this generic extensibility, systems can be developed quite simply to eliminate the need to modify the base objects. That way even the business systems developed on top of the GE can easily provide extensibility to their customer's implementation needs.

Builds in Transaction Processing

In many cases, a transaction, meaning a change to the database, has multiple steps. It is vital to the integrity of the data that the transaction occurs in its entirety or it does not occur at all. The way to accomplish this is to use transaction processing command blocks directed to the server. This ensures that an atomic transaction space wraps to the individual database commands and enables the commit or rollback of the entire transaction. The GE architecture automatically creates transactional wrappers around any changes made to the database. This makes it very easy to build a database system that automatically ensures data integrity. (Most existing systems were developed without transaction processing code because many developers are either unaware of the necessity of this part of the application, or are unfamiliar with implementation or lack time to implement it properly.)

Supports Distribution of Objects

The GE architecture automatically supports the distribution of object processing using the Aptify Object Repository.

Aptify Generic Entity versus Aptify Generic Entity Base

When reviewing the Aptify Software Development Kit (SDK), a developer may notice that the Aptify.Framework.BusinessLogic.GenericEntity namespace includes an AptifyGenericEntity class and an AptifyGenericEntityBase class. These two classes serve different purposes within the Aptify Framework:

  • AptifyGenericEntityBase defines the interface and base implementation of the Generic Entity (GE) object.
  • AptifyGenericEntity contains the complete implementation of AptifyGenericEntityBase.

When assigning variables and passing them throughout the system, especially as parameters in public or protected methods, use AptifyGenericEntityBase. When creating a new Entity object, the AptifyGenericEntity is used as the super class. In other words, Entity objects should inherit from AptifyGenericEntity, which is the complete implementation of the GE. When you sub-class, you want to start with the complete implementation and go from there.

The separation was necessary to eliminate direct circular references between assemblies in .NET. For example, the AptifyApplication object references the AptifyGenericEntityBase object in order to support methods like GetEntityObject which returns a reference to an AptifyGenericEntityBase object. AptifyGenericEntity references the AptifyApplication object in order to use some of its standard methods. That is allowed by .NET, but what is not allowed is for AptifyApplication to reference AptifyGenericEntity and AptifyGenericEntity to reference AptifyApplication. By splitting the GE into the GE and GEBase, a level of indirection is introduced and that indirection allows for the desired functionality inside the Framework. 

Was this article helpful?
0 out of 0 found this helpful



Please sign in to leave a comment.