Survey
* Your assessment is very important for improving the workof artificial intelligence, which forms the content of this project
* Your assessment is very important for improving the workof artificial intelligence, which forms the content of this project
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