Login | Register   
LinkedIn
Google+
Twitter
RSS Feed
Download our iPhone app
TODAY'S HEADLINES  |   ARTICLE ARCHIVE  |   FORUMS  |   TIP BANK
Browse DevX
Sign up for e-mail newsletters from DevX


advertisement
 

Using CSLA .NET for Silverlight to Build Line-of-Business Applications : Page 2

CSLA.NET for Silverlight provides Silverlight developers with a multitude of features from the full version of CSLA, including data binding, validation and business rules, authorization, abstract data persistence, consistent coding, and business logic encapsulation.


advertisement

CLSA Business Objects in Detail

Business object stereotypes are at the heart of any CSLA application, whether Silverlight or .NET based. A key point of CSLA .NET for Silverlight is that all business objects are shared between the Silverlight client application and a .NET application (via the data portal). These are mobile objects and they travel across physical boundaries and runtimes. Any business object has sections that implement business functionality such as business logic, property declarations, validation and authorization rules, factory methods that call the data portal, and data access methods.

CSLA .NET for Silverlight simplifies and standardizes the implementation of business logic, validation, and authorization within your objects

Class Declaration

The standard way to declare a CSLA business object is:

[Serializable] public class Company : BusinessBase<Company>

You must inherit from a CSLA base class to get the rich functionality available in CSLA. All your objects must be marked with the Serializable attribute to enable mobile object functionality.

Property Declaration

A typical CSLA .NET for Silverlight property declaration looks like this:

private static PropertyInfo<string> CompanyNameProperty = RegisterProperty<string>( new PropertyInfo<string>("CompanyName", "Company Name", string.Empty)); public string CompanyName { get { return GetProperty(CompanyNameProperty); } set { SetProperty(CompanyNameProperty, value); } }

As you can see, CSLA .NET for Silverlight simplifies property declaration. The RegisterProperty pattern should be familiar to anyone who has done any custom control creation with WPF; it is similar to the way dependency properties work. Registered properties in CSLA .NET for Silverlight provide the ability to manage backing fields for you. There are numerous advantages to that, including transfer of data through the data portal. Despite its deceptively simple syntax, SetProperty() performs a number of functions for the developer, such as running business and validation rules, verifying access rights based on authorization rules, maintaining object states (such as marking the object "dirty" when the property changes), and raising the PropertyChanged event to which the data binding is listening. All these capabilities are available out of the box.

Validation Rules

To supply validation rules, a developer must add them to the framework-supplied method:



protected override void AddBusinessRules() { ValidationRules.AddRule( Csla.Validation.CommonRules.StringRequired, new Csla.Validation.RuleArgs(CompanyNameProperty)); ValidationRules.AddRule( Csla.Validation.CommonRules.StringMaxLength, new Csla.Validation.CommonRules.MaxLengthRuleArgs( CompanyNameProperty, 50)); }

CSLA .NET for Silverlight has the same built-in validation rules as the full version of CSLA .NET, including string required, maximum and minimum string length, minimum and maximum numeric-field values, and more. In addition, developers can write and use an unlimited number of custom rules as long as they conform to a delegate declaration defined by CSLA: they must be functions that return a Boolean value.

Additionally, (new to CSLA 3.6), is the notion of asynchronous validation rules. If you create a rule that needs to make a call to a remote server you will want to make your rule asynchronous because Silverlight service calls are asynchronous. There is an asynchronous validation rule delegate in addition to the standard validation rule delegate; otherwise, the technique for creating asynchronous validation rules is the same.

Authorization Rules

Authorization rules work in much the same way as in standard CSLA—you simply specify what roles can perform which operations for a given business object:

protected override void AddAuthorizationRules() { string[] canWrite = { "AdminUser", "RegularUser" }; string[] canRead = { "AdminUser", "RegularUser", "ReadOnlyUser" }; string[] admin = { "AdminUser" }; AuthorizationRules.AllowCreate(typeof(Company), admin); AuthorizationRules.AllowDelete(typeof(Company), admin); AuthorizationRules.AllowEdit(typeof(Company), canWrite); AuthorizationRules.AllowGet(typeof(Company), canRead); AuthorizationRules.AllowWrite(CompanyNameProperty, canWrite); AuthorizationRules.AllowWrite(CompanyIdProperty, canWrite); AuthorizationRules.AllowWrite(DateAddedProperty, canWrite); AuthorizationRules.AllowRead(CompanyNameProperty, canRead); AuthorizationRules.AllowRead(CompanyIdProperty, canRead); AuthorizationRules.AllowRead(DateAddedProperty, canRead); }

CSLA performs authorization against the current principal set in ApplicationContext.User. To create a principal for CSLA .NET for Silverlight you must create a principal business object:

[Serializable] public class RolodexPrincipal : BusinessPrincipalBase { /* ... */ }

When a user logs in you simply fetch this principal like any other business object and set it to the current user of the ApplicationContext:

private static void SetPrincipal (Csla.Security.CslaIdentity identity) { RolodexPrincipal principal = new RolodexPrincipal(identity); Csla.ApplicationContext.User = principal; }

Factory Methods

The factory method is a standard pattern for exposing object creation and fetching to the consumer. In CSLA .NET for Silverlight, because all data access is asynchronous, rather than employing the standard system—passing criteria as parameters and returning the resulting object—the recommended pattern for creating factory methods is with a Continuation Passing Style (CPS). With this technique you first pass a delegate to a method that will be invoked when the asynchronous operation has completed, and then to your criteria parameters:

public static void GetCompany( int companyId, EventHandler<DataPortalResult> handler) { DataPortal<Company> dp = new DataPortal<Company>(); dp.FetchCompleted += handler; dp.BeginFetch(new SingleCriteria<Company, int>(companyId)); }

Data Access Methods

To get data into your business object you must implement the various applicable DataPortal_XYZ methods. If you are using the remote data portal, you need to implement these methods only on the .NET server version of your business objects. To fetch a Customer object, for example, you would create a DataPortal_Fetch() method. You may override the base class's DataPortal_Fetch() method or create a method that exactly matches the criteria object you passed into your DataPortal call in the factory method. CSLA will call the appropriate overload:

protected void DataPortal_Fetch (SingleCriteria<Company, int> criteria) { using (SqlConnection connection = new SqlConnection( DataConnection.ConnectionString)) { connection.Open(); /* Data Access Here */ LoadProperty<int>( CompanyIdProperty, reader.GetInt32("CompanyID")); LoadProperty<string>(CompanyNameProperty, reader.GetString("CompanyName")); LoadProperty<SmartDate>(DateAddedProperty, reader.GetSmartDate("DateAdded")); /* Load Children Here */ } }



Comment and Contribute

 

 

 

 

 


(Maximum characters: 1200). You have 1200 characters left.

 

 

Sitemap