A data access layer should be fast, efficient, and transparent to the application developer; StrataFrame’s DataAccessLayer is engineered to meet each of these criteria. This single class houses the data access logic for the entire framework. Since it remains stateless and loosely coupled, it is used by all business objects as a bridge to access the data store. The data access layer is provider independent (SQL Server, Oracle, or OLEDB), and it leverages many optimization features from the different providers that ensure delivery of excellent performance.

StrataFrame’s data access layer has been designed to be stateless, highly cohesive, and loosely coupled. Its statelessness allows all business objects to utilize an instance of the same DataAccessLayer class rather than requiring a specific implementation of a data access layer class for each business object. The data access layer is completely separated from the business layer and performs only the functions specifically required by a data access layer.

By housing an instance of the DataAccessLayer class within each business object instance, the data access layer becomes completely transparent to the application developer. The developer never calls upon it directly but rather indirectly through factory and data retrieval methods within a business object.

Improvements achieved in ADO.NET 2.0 have allowed the data access layer to become completely streamlined, efficient, and optimized. Additionally, the data access layer takes advantage of asynchronous processing, enabling it to commit records to the data store across multiple threads. By threading the data access, application latency is reduced, particularly across a VPN or remote connection.

The DataAccessLayer class contains core level support for concurrency and offers the developer three choices:

None	This setting will bypass all concurrency record handling.
Optimistic	This technique directly follows Microsoft’s definition of optimistic concurrency. (See MSDN for additional information)
Row Version	This mode allows a specific field to be specified for row versioning purposes. This is the most optimized method of concurrency support since it requires the fewest number of tests on the server to determine if a soft collision potentially exists. When a row is saved, the DataAccessLayer automatically updates the row version.
Time Stamp	Using a time stamp field is similar to using the Row Version method. When this option is used, a TIMESTAMP column is specified as the row versioning key instead of an integer-based column.

Collision Notification Options
When a concurrency exception is detected by the framework, the DataAccessLayer retrieves the conflicting record from the database and compares the local version of the record to the server of the record. If no mismatched data is found, the record is forced to save, and the end-user is never notified of the data collision. If mismatches are found, then the end-user is notified that someone else modified the record first and the end-user is presented with a form that allows them to correct the concurrency issues before saving the record again.

This auto-handling of data collisions can be disabled, and there are properties that determine how the developer will be notified if a concurrency exception occurs. By default, an event is raised that is automatically handled by the business object's parent form (to present the end-user with the list of mismatched values), but a business object can be configured to throw an exception when a collision occurs.

The DataAccessLayer class has been synchronized to prevent unwanted repercussions stemming from simultaneous access by multiple threads. Requests for data can be made by the business layer on different threads without requiring the developer to explicitly synchronize those requests. Furthermore, events raised by the data access layer are explicitly raised on the main application thread to prevent cross-thread exceptions as the events are bubbled to the user interface.

Stored Procedures
CRUD settings are critical when attempting to achieve the most optimized and streamlined insert, update, and delete performance between the DataAccessLayer and the database. In some cases, company policy forces a developer to use stored procedures on all CRUD interaction. In these situations the CRUD options are not only helpful; they are vital. A stored procedure can be specified for each CRUD operation (INSERT, UPDATE, and DELETE) through properties on the business object, which uses those settings in turn when interacting with the DataAccessLayer.

Primary Key Value Auto Retrieval
When a new record is created, the primary key value(s) are automatically retrieved and updated within the internal data source of the business object. This feature can be adjusted through the CRUD settings as well.

Unlimited Server Connections
Oftentimes a developer may have more than one data source that will be viewed, updated, and deleted. This is especially common when interacting with disparate or legacy data. Therefore, a StrataFrame application allows an unlimited number of connections that can be accessed within the application simultaneously. The separate connection strings needed for each connection are managed by the Connection String Manager provided by StrataFrame.

Multiple Database Type Support
Expanding upon the unlimited server connections is the capability to connect to an unlimited number of databases at the same time. This includes different database types such as SQL Server and FoxPro. This functionality is significant because it allows business objects to communicate to SQL Server and FoxPro databases, for example, on the same form, and the developer does not have to manage these connections. This is an advantageous means of migrating existing legacy applications forward incrementally, or of creating streamlined data conversions.

Custom SELECT Statements
Unlike many other frameworks and O/R Mappers, a custom SELECT statement or stored procedure can be easily executed for data retrieval. The developer is not limited to the stored procedures and pre-generated SELECT statements used by the data access layer.

Parameterized Commands and Stored Procedure Queries
Another useful data retrieval option is a DbCommand. This is the best data retrieval option when creating dynamic queries or when a WHERE clause will be stated, since the DbCommands have parameter support. A parameterized DbCommand can also call a stored procedure.

Non-Database Specific Queries
There are circumstances where the backend database may change from one type to another depending upon the deployment environment. The StrataFrame QueryInformation allows developers to create provider-independent queries that are converted to the appropriate provider-specific SQL syntax by the database's specific DbDataSourceItem implementation. This powerful feature allows a single query to be written and re-used to query SQL Server, FoxPro, Oracle, or any database type being used by the application, as long as there is consistency between the data structures.

Scalar Support
StrataFrame has full scalar support, which allows a developer to quickly retrieve a single piece of data or to execute a query that performs a simple calculation and returns the calculated value.

Unlimited Simultaneous Transactions
StrataFrame takes complete transaction support to a new level by allowing an unlimited number of transactions to be processed at the same time. Transaction objects are managed by the framework allowing a "hands-free" approach to transaction processing. Each transaction can be individually controlled, and all business objects have the ability to be included or excluded from the transaction. This can be very beneficial when a large transaction is being processed and the developer wants to save data from another business object on a separate transaction or off a transaction entirely.

Simple Programmatic Access
The transaction processing can be control through very simple and accessible methods and is as simple as calling TransactionBegin() along with TransactionEnd() or TransactionRollBack(). Any errors or notifications that need to be managed will be automatically presented to the developer, who then must simply decide which action to take.

The debug mode provides a complete view of each SQL statement executed on a data source, including SELECT, INSERT, UPDATE, and DELETE statements. Each statement is written to a log file in HTML format showing the SQL syntax, parameters, transaction context, connection, and many other pieces of information. This feature is invaluable when trying to track down any type of error stemming from data processing that cannot be easily debugged through Visual Studio.