Component-based Scalable Logical Architecture

From Wikipedia, the free encyclopedia

Component-based Scalable Logical Architecture (CSLA) is a software framework created by Rockford Lhotka that provides a standard way to create robust object oriented programs using business objects. Business objects are objects that abstract business entities in an object oriented program. These entities could be things such as sales orders, employees, or invoices. CSLA was originally targeted toward Visual Basic 6 in the book Visual Basic 6.0 Business Objects by Lhotka ISBN 1-86100-107-X. With the advent of Microsoft .NET, CSLA was rewritten with no code carried forward and called CSLA.NET. This revision took advantage of Web Services and the fully object oriented languages that came with Microsoft .NET(i.e. Visual Basic.NET and C#). CSLA.NET was expounded in Expert C# Business Objects ISBN 1-59059-344-8 and Expert One-on-One Visual Basic .NET Business Objects ISBN 1-59059-145-3, both written by Lhotka. Though CSLA and CSLA.NET were originally targeted toward Microsoft programming languages, most of the framework can be applied to most object oriented languages.

Contents

[edit] Features of CSLA

[edit] Smart data

A business object encapsulates all the data and behavior (including persistence logic) associated with the object it represents. For example, an order object will be the only part of the program to load an order, obtain or assign the order's member data (order numbers, etc...), save the order, and so on.

[edit] Typed Collections

The framework defines a standard way to create collection objects which represent a collection of objects. This allows an object model to map well to a relational database's data model. For example, an Account table could map to an Accounts (observe the pluralization) collection object (in reality the object model will differ from the relational model, it is therefore necessary to employ Object-Relational Mapping to resolve the differences). In this case each row in the Account table would map to an Account business object which is contained in the Accounts collection object. This makes it possible to define methods for the collection object that will propagate to its constituent objects. For example, to save all the Account objects in an Accounts collection, one would type:
myAccountsCollection.Save();
The Save() method will call the Save() method on each of its constituent Account objects.

// Inside the Accounts class
public void Save(){
    // _accounts will normally be some type of array variable with class scope
    // that holds all of the Account objects represented in this collection.
    foreach (Account acct in _accounts){
        acct.Save(); // The actual Account object does the work of saving itself to the database
    }
}

This method of propagating changes to a collection's constituent object can be used for other common methods and property assignments as well(myAccountsCollection.Load(); myAccountsCollection.Active = false;). Business objects can also contain other collection objects, in effect creating a relationship analogous to a parent child relationship between two tables. For example, the Account object mentioned above can contain an Orders collection object which in turn contains Order objects. In this case, the above call to Save() on the Accounts collection object could be written to save all of the Account objects as well as all of the orders associated with each of the accounts.

[edit] Object persistence

Data creation, retrieval, updates, and deletes (CRUD) are performed by clearly defined methods of the business object associated with the data testing.

[edit] Persistence state maintenance

CSLA defines a standard way of allowing a business object to maintain information about its "persistence state". In other words, an object knows 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.)

[edit] 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 back 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.

[edit] 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.

[edit] Extended features of CSLA.

[edit] Simple UI creation

Using Windows Forms or Web Forms, data-bound controls like DataGrids and ListBoxes can be bound to business objects instead of more generalized database objects like ADO.NET DataSets and DataTables.

[edit] Distributed data access

Using Web Services, an object can perform its data access on the client machine or a server. It can also be configured to use manual database transactions or distributed two-phase commit transactions.

[edit] Web Services support

Business logic created with the CSLA.NET framework can easily be exposed as a web services to remote consumers.

[edit] External links