he CSLA framework, written by Rockford Lhotka, has been around for over a decade. CSLA's purpose is to give developers a solid framework to house business logic for applications. Microsoft .NET developers have adapted CSLA to new technologies as they emerge, and many developers use CSLA .NET heavily to construct robust, scalable .NET-based solutions supported on all Microsoft UI platforms, Windows, and the web. CSLA .NET for Silverlight follows that lead, letting developers create a Silverlight-compatible object-oriented business layer that abstracts and encapsulates your business logic and data, simplifying and standardizing business logic implementation, data validation, and user authorization within your objects. The goal is to provide an easy and consistent coding pattern by which you can encapsulate all your business logic within your object-oriented business layer. The result is a business layer that supports development of rich, interactive Silverlight applications.
CSLA .NET for Silverlight's key features remain the same as in other versions: full support for Silverlight data binding, N-level undo, authorization/authentication features, validation rules, abstract data persistence, mobile objects that span physical boundaries to perform business functions, and multi-tier deployment model support.
You can use CSLA .NET for Silverlight to develop Silverlight-based scalable line-of-business applications. Because Silverlight applications run in a Web browser, these applications require an application server component.
CSLA .NET for Silverlight has two primary ways to interact with an application server, the most common of which will probably be the CSLA .NET for Silverlight remote
data portal. In this scenario, the Silverlight client calls the data portal for all CRUD operations and the data portal invokes CSLA .NET components on the server. In this case, CSLA .NET for Silverlight-based applications will still use CSLA .NET functionality to implement the data portal and business objects will move between the client and server just like they do in .NET.
The other primary scenario uses the CSLA .NET for Silverlight local data portal. In this case, the Silverlight client calls the data portal, but the data access code runs on the Silverlight client. These data access methods typically make calls to an external service (for example a WCF service, ADO.NET Data Services, or traditional Web service) to get or update data.
CSLA .NET for Silverlight supports the following standard CSLA business object stereotypes:
|Figure 1. Solution Structure: Here's how a CSLA .NET for Silverlight-based application looks in Visual Studio's Solution Explorer.|
- Editable root
- Editable child
- Read-only root
- Read-only child
- Editable root list
- Editable child list
- Read-only root list
- Read-only child list
- Name/value list
- Dynamic root list
- Dynamic root
CSLA .NET for Silverlight Example
You need a number of projects to implement a CSLA .NET for Silverlight solution (see Figure 1
). The first project is a .NET class library (Rolodex.Business.Server) that shares business object class files with the Silverlight class library (Rolodex.Business.Client). You also need a Silverlight application project (Rolodex
) that compiles into the Silverlight XAP file/executable assembly. Finally, you need a web project (Web
) to host the Silverlight application. This project can, at the same time, host the CSLA .NET data portal application server components. Alternatively you can create a separate project to host the data portal (WcfHostWeb
|Editor's Note: This article was first published in the November/December 2008 issue of CoDe Magazine, and is reprinted here by permission.|