Overview
The middle layer of an application created using StrataFrame consists of one or more 
business objects that inherit from the abstract BusinessLayer class. This class provides 
base functionality for all tasks, including business object population, business rules 
handling, validation, data retrieval, and data navigation. Program in Preferred .NET Language
StrataFrame has no proprietary or scripting languages that must be learned.  All logic can be 
completely coded in any managed .NET language, including VB.NET and C#.  This increases the speed 
of development and allows business logic to be reusable.
 Strong-Typed Business Objects
Represents Data Structure
StrataFrame provides the ability to strong-type the business object column properties easily and 
quickly using the  Business Object Mapper.  Properties are created on each business object and reflect 
the actual data columns of the represented structure.  
 Improved Code Reliability & Intellisense
Since the field properties are strong-typed, code reliability improves.  The foremost reason for this
is that almost all data type mismatches can be resolved at compile-time rather than emerging at 
run-time.  Using a strong typed field in a manner inconsistent with its data type will produce 
a compiler error, while using a weak typed field in the same scenario will not.
 
Extended Strong-Typing
There are many instances in which a column in a database represents a type other than what is stored as raw 
data.  For example, a column in a table may be typed as INT, but when the developer interacts with the field property 
on the business object, he or she needs the ability to have it typed as an enumeration and to have the value automatically 
persisted back to the database as INT.  In another example, a data column may be typed as VARBINARY or IMAGE but actually 
represent a bitmap or serialized object; StrataFrame allows the field property on the business object to be strong typed 
as the serialized object type and will automatically 
serialize and deserialize the data to and from the database without writing a single line of code.
  Advanced Native Support
The business layer of StrataFrame contains features that alleviate many of the mundane tasks 
that normally plague application development.  These features allow the developer to focus on 
the specifics of the application rather than investing time in the creation and maintenance of
baseline functionality.
 Compound Primary Key Support
StrataFrame natively supports compound primary keys within table structures.  This support is 
extended to all 
navigation and query methods within a business object and is ready for use out-of-the-box.
 
Auto-Bound Error Provider
A .NET ErrorProvider is utilized to display errors and broken business rules to the end-user.  
The implementation of the error provider requires no code from the developer and its appearance
can be extensively customized through properties including the ability to disable the error provider
completely.
 Full Parent-Child Relationship Management
Relationships are configured on a per-class basis for business objects within a StrataFrame 
application's business layer.  Once configured, 
the BusinessLayer class will automatically manage the primary key/foreign key relationship; new 
child rows will be assigned the foreign key value of the primary key from the corresponding 
business object.  When new records are saved, the primary key value the database 
server assigns is propagated through the relationships to the child business objects.  The 
management of the relationship is also used to ensure new parent records are saved before
the corresponding child records are saved.
 Field Initialization and Priority Control
By default, all fields on a new record are initialized by data type to prevent any run-time DBNull 
errors.  This feature can be disabled by setting a single property.  Additionally, all business objects 
can be given an initialization priority which allows the developer to control the order in which 
objects on a form are initialized.
 Patterned but Simplified
The BusinessLayer class follows best the practices for object-oriented programming and 
utilizes many established design patterns.  Only a single class is created for each 
business object in a StrataFrame application. By inheriting from the BusinessLayer 
base class, business objects enjoy all of the necessary functionality mentioned 
in the overview.  This tightly integrated and cohesive single-class design is of high 
significance to the developer because it greatly improves the simplicity of the application
when compared to the 5 to 7 classes per business object typically required 
by other commercial framework options.  
 Optimized for Performance
The business layer has been optimized to deliver a high level of performance for the
application developer.  
A DataTable, rather than a DataSet, is used within the business 
object in order to reduce the memory footprint of each instance 
of a business object.  Custom data navigation has been implemented to allow the 
developer to iterate through the records within a business object (sorted or unsorted, 
filtered or unfiltered) more rapidly than iterating through the entities within a 
custom entity collection.
 
Centralized Location for Business Logic
All business logic is housed within its corresponding business object class.  
Additional classes are not required for business rules, data validation, default 
values, etc.  Required fields are implemented by the BusinessLayer base class and do
not necessitate any code from the developer.  This centralization simplifies the developer's 
coding process and improves performance by keeping class instantiations and 
server round trips (to check server-side logic) to a minimum.
 Simple Required Field Implementation
Though the required field logic can be manually programmed, StrataFrame provides a quick 
and easy way to specify fields that require entry by simply clicking a check box.  Every business
object contains a collection aptly named RequiredFields.  Through the component designer within Visual 
Studio, the fields that require entry can be set using the integrated type editor.
 Integrated Localization Support
All areas of StrataFrame are localizable, including the business logic.  Instead of hard-coding 
broken rule messages within the code, they can be pulled from a localization database through the 
extensive  Messaging and Localization support.
 Customizable and Extendable
In concert with the other elements of the StrataFrame Application Framework, the business 
layer is designed to empower developers, not limit them.  The BusinessLayer class provides 
a great deal of flexibility and functionality that can be overridden or modified.  Moreover,
strategic properties are exposed, which enables the developer to toggle much of the 
automation within the business objects.  Field properties created by the Business Object Mapper 
can be customized or replaced by custom code that the developer provides.
 Boundless Programmatic Access
Whether used programmatically or configured for data-binding to controls, StrataFrame business 
objects are designed for ease-of-use.  With the strong typed fields on a business object, 
all of the field properties are available within the Intellisense supplied by the code 
editor within Visual Studio.  You will never need to look at a 
reference chart to check the names of your fields again.  Programmatic access 
is further enhanced by the base class methods that can be used to seek, filter, navigate, 
iterate, or sort records within the business object.
 Event Driven Hooks
Many event driven hooks are intrisically provided to give the developer complete control 
when interacting with the business objects.  There are a wide range of events that exist providing 
the developer with complete control.  This methodology allows a much more precise interaction with 
the environment and prevents the need for method overrides.  The hooks include such events as before, 
after, security, state change, error, concurrency, data change notifications, new record default 
value initialization, and more.
 Extensive Navigation Methods
Changing the CurrentRow of the businesss object is made easy through functionality provided 
by the BusinessLayer base class. When invoked the data navigation methods will modify the 
CurrentRowIndex and change the row accessed by the actual strong-typed field properties.  Support for 
ADO Style, FoxPro, and UI Bound navigation exists with such methods as: MoveFirst(), MoveNext(), 
MovePrevious(), MoveLast(), MoveAbsolute(), Seek(), SeekToPrimaryKey(), Navigate(), and NavigateToPrimaryKey().
 Sorting and Filtering
The data within the business object can be sorted or filtered easily by the developer. Optionally, the current filter can be propagated to child business objects. 
 Exposed ADO.NET Components
Though StrataFrame manages all of the necessary tasks required for robust application development 
there are times when direct access is required by a developer.  When such situations arise, the 
ADO.NET components are directly accessible through exposed properties on the busines objects.  This 
includes properties such as: CurrentDataTable, CurrentView, CurrentRow, and CurrentRowIndex.
 Broken Rules Collection
When the need arises to direclty interact with the broken rules, a collection exists on all business 
objects that allow the developer to manipulate and display the broken rules as desired.
 Grid and Third Party Binding Support
All business object have the ability to natively support grids through the exposed ADO.NET properties.  
Grid support provides native event interaction allowing the developer to monitor the navigation events 
without adding any code.  Also, most any third party control can easily interface to the business through binding support options 
made available in StrataFrame.
 XML Data Source Support
At times, it is necessary to use an XML file as a data store.  When this need arises, a business object 
can be strong typed and read from and write to an XML file.  Additionally, this XML file can be dynamically 
encrypted and decrypted by calling a single method.
 Business Object Serialization
Business objects have complete serialization support.  This allows a business object to be 
save and restored to disk in its complete state.  Moreover, a business object can be serialized to and from 
a stream allowing a business object to be handed out from a single location passed through a network 
connection.  This provides support for enterprise services, remoting, and web services.
 Technical Specifications| expand all | collapse all |  |
   |  Strong Typed |   |  |   | 
Properties are created on each business object and reflect the actual 
field values of the internal data table. The properties are populated 
as a byproduct of the framework’s navigation methods.  This simplifies 
access to the simple mybo.myfield vernacular, totally 
alleviating the requirement of indexes being passed.
 |  |   |  
  |    |  Data Navigation |   |  |   | 
Changing the CurrentRow of the businesss object is made easy through 
functionality provided by the BusinessLayer base class.  When invoked 
the data navigation methods will modify the CurrentRowIndex and change 
the row accessed by the actual field properties.
- ADO-style Navigation
 MoveFirst() 
MoveNext() 
MovePrevious() 
MoveLast() 
MoveAbsolute() - FoxPro-style Navigation
 Seek() 
SeekToPrimaryKey() - UI-bound Navigation
 Navigate() 
NavigateToPrimaryKey() 
  |  |   |  
  |    |  Sorting & Filtering |   |  |   | 
The data within the business object can be sorted or filtered easily by 
the developer.  Optionally, the current filter can be propagated to child 
business objects.
 |  |   |  
  |    |  Exposed ADO.NET Components |   |  |   | 
All ADO.NET components used within the business object are exposed for 
developer interaction.
- CurrentRow -– The DataRow currently 
used by the field properties on the business object.  This row is 
determined by the CurrentRowIndex of the CurrentDataView.
 - CurrentDataTable -– The internal 
DataTable of the business object that houses all data.
 - CurrentDataView -– The DefaultView 
of the internal data table that allows the business object to be sorted 
and filtered.
 
  |  |   |  
  |    |  Event Driven Hooks |   |  |   | 
Hooks are provided for the developer to extend the functionality of the business
objects.
- Pre- Hooks
- BeforeSave
 - BeforeDelete
 - BeforeUndo
 
  - CurrentDataTable
- AfterSave
 - AfterDelete
 - AfterUndo
 
  - Security Hooks
- CheckSecurity -- raised when a business object attempts to 
add, edit, delete, or save a record, allowing the developer to 
determine if the user has the required privileges.
 - CheckFieldSecurity -- raised when the business object is 
configured to check field level security and allows the developer 
to block specific fields from being viewed by the end-user.
 
  
  |  |   |  
  |   |  |
   |  Properties Automatically Created and Maintained |   |  |   | 
The strong-typed field properties on each business object are created and 
maintained through the Business Object Mapper.  The Business Object Mapper 
directly integrates with Visual Studio and allowing it to modify the files 
from within the IDE.  The field properties are stored in the partial class 
file used by the component designer.
 |  |   |  
  |    |  Custom Data Types |   |  |   | 
Field properties are not limited to the primitive data types, but each can 
be assigned a custom data type.  Common custom data types include enumerations 
that allowing the business object to return the typed enumeration but still 
store it in the database as an integer type.
 |  |   |  
  |    |  Object Serialization |   |  |   | 
Field properties can also be complex, serializable data types.  When configured, 
a field property will serialize and de-serialize an object into and out of a 
field property, storing it in the database as a binary field type.  For example, 
a bitmap image could be serialized when it resides on disk then de-serialized 
for use on the presentation layer; a System.Drawing.Bitmap object would be returned
by the field property rather than a Byte[].
 |  |   |  
  |    |  No UML or XSD |   |  |   | 
The developer is not required to maintain a collection of UML, XSD, or XML files 
to define the field mappings for each business object.  The Business Object Mapper 
can use either the data source or the meta-data within the Database Deployment 
Toolkit to derive the schema for the business object.
 |  |   |  
  |  
  | | expand all | collapse all |  |
   |  All Business Rules Checked in a Single Event |   |  |   | 
A hook event is provided to check business rules.  All business rules logic is 
placed within the handler of this event.  It is raised from within the 
BusinessLayer base class when the business object is saved.  It is also raised 
if the developer explicitly calls a rules check.  
 |  |   |  
  |    |  Simple Required Fields Implementation |   |  |   | 
A required-fields collection is implemented through the BusinessLayer base 
class and each required field is actually selected via a simple to use editor.  
These required fields are checked when the business rules are checked, and 
broken rules are automatically added to the broken rules collection for each 
required field not entered.    
 |  |   |  
  |    |  Broken Rules Collection |   |  |   | 
When business rules are checked, broken rules are added to the business object.  
The most recent collection of broken rules is available to the developer through 
the BusinessLayer base class.
 |  |   |  
  |    |  Auto-Bound Error Provider |   |  |   | 
A .NET ErrorProvider is utilized to display errors and broken business rules to 
the end-user.  The implementation of the error provider requires no code from the 
developer and can be toggled.
 |  |   |  
  |    |  Program in Preferred .NET Language |   |  |   | 
Many application frameworks implement their own scripting language that is used 
to program business rules.  With StrataFrame, the developer does not have to learn 
a new scripting language to check the business rules as all business logic is 
programmed in the .NET language used to create the business object.
 |  |   |  
  |    |  No Server-Side Code for Business Rules |   |  |   | 
While the developer can use any combination of server-side and client-side 
logic to check business rules, StrataFrame does not require any server-side 
code. Many business rules require a database query or a file system check; 
this is possible, as all business rules are coded within .NET rather than 
T-SQL or a proprietary scripting language.
 |  |   |  
  |   |  |
   |  Data Access through DataAccessLayer Class |   |  |   | 
Each business object contains an internal instance of the DataAccessLayer 
class.  This object provides the interface between the business object and 
the data store.  The BusinessLayer base class provides several protected methods 
for the developer to interface with the data access layer.
- Population Methods -- All population 
methods replace the internal data table with the result set returned by 
the data access layer:
 FillDataTable(SELECT) 
FillDataTable(DbCommand) 
FillByPrimaryKey() 
FillByParentPrimaryKey() 
FillByParent() - Retrieval Methods -– All retrieval 
methods return a DataTable filled with the result set returned by the 
data access layer:
 
GetDataTable(SELECT) 
GetDataTable(DbCommand) 
GetByPrimaryKey() 
GetByParentPrimaryKey() 
GetByParent()
 Note: The retrieval methods do not interrupt the actual 
business object (internal data table).  The newly fetched data is
autonomous and does not interfere with any existing process of the 
current business object.
 - Factory Methods -– Constructors are 
provided by the BusinessLayer base class that allows the developer 
to implement custom factories or shared factory methods directly on 
the business object class.
 
  |  |   |  
  |    |  Relationship Management |   |  |   | 
The BusinessLayer base class manages relationships by synchronizing primary key 
values with corresponding foreign key values.  The relationships are configured 
at the class level of each business object.  
 |  |   |  
  |    |  Force Save of Parent If Child is Saved First |   |  |   | 
If a relationship is defined on a child business object and the child tries to 
save while the parent business object is still "dirty," the child business 
object will force the parent business object to save.  This allows the new 
primary key values assigned to the parent business object by the data store 
to be propagated to the child business object before it is saved.
 |  |   |  
  |    |  ChildAutoFilter |   |  |   | 
A business object can be configured to automatically filter records on child 
business objects so that only records that correspond to the parent records 
are visible within the child.
 |  |   |  
  |  
  |  
  |