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 Specificationsexpand 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.
| | |
|
|
|