Editing Component-based Scalable Logical Architecture (section)

==Features of CSLA==

===Smart data===
A business object encapsulates all the data and behavior (business logic and rules) associated with the object it represents. For example, an OrderEdit object will contain the data and business rule implementations necessary for the application to correctly allow the user to edit order information.

===Rules engine===
The CSLA .NET framework provides a rules engine that supports validation rules, business rules, and authorization rules. These rules are attached to object instances or properties, and are automatically invoked by CSLA .NET when necessary. Validation rules may be implemented using the CSLA .NET rule engine, or through the use of the [[DataAnnotations]] feature of [[Microsoft .NET]].

===Object persistence===
Data creation, retrieval, updates, and deletes ([[CRUD (acronym)|CRUD]]) are performed by clearly defined methods of the business object associated with the data testing. Data access logic is clearly separated from business logic, typically using a [[repository pattern]] or other mainstream [[object-oriented programming]] techniques.

===Metastate maintenance===
CSLA .NET manages the ''metastate'' about each business object. For example, each business object tracks information about when it is new (it represents data that hasn't been saved yet) and when it is dirty (it needs to be saved to the database either because it is new or because its member data has been changed since it was last loaded).  Business objects can also be marked for deletion so they can later be deleted (for example when a user has pressed a button confirming his or her intention to delete the rows.)

===''n''-Level undo===
This feature makes it possible for an object or collection of objects to maintain a collection of states.  This allows the object to easily revert to previous states. This can be useful when a user wants to undo previous edits multiple times in an application.  The feature can also allow a user to redo multiple edits that were previously undone.

This feature can provide rich functionality for desktop application and web applications.  One note of caution would be to consider the overhead for high-transaction web-based applications.  n-Level undo capability will require storing the previous state of an application generally accessed by reflection.  This is common practice in desktop applications where changes must be "Applied".  In web based designs, the added storage may pose unnecessary overhead as changes are generally submitted in batch and do not require the same level of "undo" capability.

===Business rule tracking===
Allows objects to maintain collections of "broken rule" objects.  Broken rules will exist for an object until it is in a valid state, meaning it is ready to be persisted to the database.  ''BrokenRule'' objects are usually associated with validation logic such as ensuring that no alphabetic characters are entered into a phone number field.  For example, if an ''Account'' object has a ''PhoneNumber'' property, and that property is assigned a phone number with alphabetic characters, the ''Account'' object's ''IsValid'' property will become false (making it impossible to save to the database) and then a new ''BrokenRule'' object will be created and assigned to the Account's ''Broken Rules'' collection.  The rule will disappear when the invalid phone number is corrected making the Account object capable of saving itself to the database.