An Introduction to Business Objects in C#

答案：
Download source files - 22 Kb 
Note: after downloading be sure to consult ReadMe.txt first. 
Introduction
This sample is an introduction to Rockford Lhotka's Component-based Scalable Logical Architecture (CSLA) as described in his book, Visual Basic 6 Business Objects (Wrox Press, 1998). The CSLA is an implementation of n-tier design, where an application is logically partitioned into four layers - presentation, UI-centric business objects, data-centric business objects, and data services. The purpose of the architecture is to achieve two overarching objectives. 
Scalability. 
Flexibility in the physical placement of each layer. 
The latter means that we can decide whether to place all the layers on a single machine or to distribute them between client and server machines with little or no impact on the business logic code. It also means that we can provide a variety of presentation layers, ranging from a traditional Windows interface to a Web interface, with little or no impact on the business logic code. A typical physical architecture, utilizing a rich Windows-style user interface, is to place the UI- centric objects on a client workstation where they are close to the user interface. The UI- centric objects communicate with the data-centric objects, which are placed on an application server, and the latter communicate with the data services, which are on a database server. The code presented here in C# is not a full implementation of the architecture. Rather, it serves to illustrate the basic ideas. It presents a single UI-centric business object that captures basic information about a person - social security number, name and date of birth. It shows how a Microsoft .Net Windows Forms user interface can interact with the business object while allowing the latter to validate all the business rules as the user enters data. The user interface is completely insulated from detailed business rule validation. It just needs to act on a property of the business object - whether it is currently in a valid or invalid state. UML Class Diagram 
The Person Class 
The Person class has three supplied properties: 
Social Security Number 
Name 
Birth Date 
and one computed property: 
Age 
It has three business rules. 
Social Security Number contains exactly 11 alphanumeric characters (though the sample asks the user for digits). 
Name must be non-empty. 
Birth Date must be in a valid format. 
A Person object is not considered to be in a valid state until these rules are satisfied. In order to provide the richest and most responsive user experience the idea is to validate these rules while the user is entering their data, rather than after it has all been entered. Other user interfaces, such as an HTML 3.2 interface, can make do with a "batch"-style interface but we want to be able to use a variety of user interfaces and a Windows-style GUI provides the richest. The basic idea is that the controls for saving the user's data should only become available when the user has supplied all the data necessary to make a Person valid. It is the user interface developer's job to write the code to do this. But they don't need to write detailed validation code they need only query the Person's "Valid" property. However, in practice, the UI developer has to know more about a Person than this. But what they have to know is not to do with business rules but with the operational state of a Person at any time. Let's consider the operations that can be performed on a Person: 
Add a new Person. Save it to a database. Load an existing Person from the database. Delete a Person.
A rich user interface will have features that enable a user to: 
Edit their data, save their changes and close the application. Edit their data, save their changes, do further editing, save and close. Edit their data, cancel their changes, and close. 
And so on. In a data entry form the above is typically implemented using OK, Cancel and Apply buttons. This might not seem particularly problematic. However, a feature of this architecture is that the Person object's state is being updated as the user types. If the user cancels their edits it is important to restore the object to the last valid state it was in prior to the edits. This means we have to keep a copy of the current state after each Apply operation. In this particular example, this doesn't matter but in a more complex application, say, with collections of Persons, it would. And we are trying to illustrate the general principles. The UI developer also needs to know a few other things about a Person, such as whether a Person is new, modified (dirty), or is currently being edited. For example, it should not be possible to load a new Person from the database while one is being edited. 
Managing Edits 
To facilitate editing, three methods are provided: BeginEdit This enables editing. ApplyEdit Saves or deletes object if appropriate and terminates editing. Clients should immediately call BeginEdit if they wish to continue editing. CancelEdit Cancels all changes since the last ApplyEdit operation or since the object was marked for deletion. Terminates editing. In database terminology these three methods function like "BeginTrans", "Commit" and "Rollback" respectively, but applied to an object rather than a database. 
Managing Business Rules 
In Rockford Lhotka's original Visual Basic implementation he created a BrokenRules class that was made available to every business object in the application. In this sample, I have moved this functionality into an abstract base class, BusinessObject. I could also have placed an abstract interface to the three editing methods here while deferring the implementation to Person, but I chose not to for this sample. The validity or invalidity of a Person object is determined by maintaining a collection of broken business rules. The object is invalid while the collection is non-empty. When the count goes to zero the object becomes valid. The method that maintains the collection is: void RuleBroken(string rule, bool isBroken) where: rule is a description of the business rule. This can be as simple as just the name of the property, e.g., "Birth Date" isBroken indicates whether the rule is broken or not. When a rule becomes broken it's added to the collection. If it's repeatedly broken the algorithm just skips adding it. When it becomes unbroken it is removed from the collection. When a Person object is first constructed all its fields will be empty, so all its rules will be broken. Remember, the rules are: 
Social Security Number contains exactly 11 alphanumeric characters. 
Name must be non-empty. 
Birth Date must be in a valid format. 
In the Person constructor we write: RuleBroken("Social Security Number", true); RuleBroken("Name", true); RuleBroken("Birth Date", true); Of course, this is not normally how we should construct objects. Normally objects should always be constructed in a valid state. However, the object being discussed here is a special kind. And when anything important is being done to it, such as persisting it or restoring it, the method ensures that the object is valid before it's persisted or after it's restored. 
Making a Person Valid 
The idea is that a Person should move from an invalid to a valid state as the user types in their data. Initially each item that is the subject of a business rule will be incorrect. Then one by one, as the user completes a data entry field, each should become valid until Person becomes valid. This is achieved by appropriately constructed Person set_xxx prop

上一个：C#中调用API
下一个：ref和out关键字初解