Download Application Framework Guidelines

Application Guidelines
Application Framework Definitions
Common Layer
The common layer is where strongly typed data is stored as Data Source objects
(DSO). All data in the database that is accessed directly will have its own DSO. Data that
is always accessed in conjunction with another piece of data will be combined in to a single
DSO. Classes at this layer provide access to properties that expose the Name, Data Type,
Length and Value of Database fields as well as table, stored procedure and parameter
names.
Business Façade Layer
The Business Façade is the point of interaction for all user interface development.
Front end application need only reference the Business Façade and the Common layer to
perform all application functions. Methods at the Business Façade should Provide Data that
Clients Need to Issue Valid Requests
Business Rules Layer
The Business Rules layer is where the rules to manipulate a singe instance of an
entity collection. i.e. To act on a single person from a list of people or a single course from
a list of courses
Data Access Layer
The Data Access layer is use to access the database in order to return one or more
records from the database. i.e. Get one student or get all students for a class
Example:
The following objects are used to performs actions that relate to Receivables
Business Façade - The ReceivableSystem object is the object that simplifies access to the
other objects by giving you a single method to call to get or manipulate the data you want
such as CreateReceivable which accepts a message containing all of the information
necessary to create a new receivable entry including the information needed to create a new
debtor.
Business Rules - The Receivable object is where the business rules for manipulating a single
receivable. This is where we validate that the debtor id passed to the CreateReceivable
method actually exists.
Data Access - The ReceivableTbl object is where all of the functions that allow for the
selecting, inserting, updating and deleting of data are defined
Common Data - The ReceivableData object is where the Receivable DataSource object is
defined. This class provides access to properties that expose the Name, Data Type, Length
and Value of Database fields as well as table, stored procedure and parameter names.
Bases on the requirements for this particular project and development team the following
guidelines were developed.
Object Granularity
Methods should be placed in the same class module when only as they relate to the same
business process. i.e. Things that relate to creating or manipulating a receivable should be
placed in the same object.
A) Methods that relate to the same business process should be placed in the same class at
the appropriate layer as defined by the layer placement guidelines.
B) Methods relating to a business process that can be executed independently of any other
business process should be placed in a multi use class (a public class).
For example: Methods that allow the addition deletion and editing of values in
SourceSytemType table could be executed without the need to create a receivable and
therefore should be defined in a multi use (public) class.
C) Methods can be split out into separate private classes for maintainability reasons.
1. Methods split out for maintainability should be organized by business function.
For example: Methods to create or check for the existence of a source system
could be slit out into a separate class because both methods perform action relating
to the source system
2. Methods can be developed in a single monolithic class and spit out as required
for readability.
Method Return Value Data Types
Layer Placement
Methods should be placed at each layer and in separate class modules based on the following
guidelines…
The User Façade
The Business Facade
Methods at the Business Façade should Provide Data that Clients Need to Issue Valid
Requests
Microsoft calls classes (Objects) that contain these type of methods Emissaries.
Emissaries are responsible for helping Windows DNA application clients issue perfectly
formatted requests for executants to perform various business operations. This
responsibility includes providing clients with any supplemental information they need from
the application to formulate valid business operation requests. To identify such
supplemental data, developers must analyze each business operation request. For example,
the DNA PurchaseOrder application requires clients issuing purchase order creation
requests to provide several pieces of information, including the order's destination shipping
address and the inventory ID of each item they wish to purchase as part of the order.
While the user doesn't require any supplemental information from the application to supply
the order's destination shipping address, the user does need the application to provide the
inventory IDs of the various items the user wants to purchase. The DNA PurchaseOrder
application provides users with this information by presenting a list that includes each
inventory item's ID along with its description, cost, and current quantity on hand.
The Business Rules
Methods at the Business Rules should perform the Business Operations and enforce the
business rules
Methods at the business rules layer should include the steps that are “always” taken to
perform a particular action. For example: When you create a new receivable you always
create a receivable business data entry to map the new receivable back to the source
system. On the other hand you do not “always” create a debtor, because one may already
exist.
Microsoft calls classes (Objects) that contain these types of methods Executants.
Once a Windows DNA application's business operations and respective request syntaxes
have been defined, the next step is to create the executants that will ultimately perform
the application's business operations. The DNA PurchaseOrder application relies on the
AccountsExec, InventoryExec, LineItemExec, and PurchaseOrderExec executants to
perform the business operations defined earlier in Tables 6-9, and relies on the
UniqueIDGen and UniqueIDAllocBatch objects to generate the primary key values for each
row inserted into the application's underlying database tables. While executants are
ultimately responsible for performing business operations, they are free to use whatever
means necessary. Some Windows DNA applications issue batches of SQL statements to
manipulate and update their underlying data source(s), while others like the DNA
PurchaseOrder application rely on the increased performance offered by SQL stored
procedures. The SQL stored procedures required to perform the business operations of the
DNA PurchaseOrder application are described in the following table.
The DataAcess Layer
The Common Layer