Browse by Tags

• CSLA .NET

• Using CSLA Light, Part 1

  In preparation for the next public release of CSLA Light (CSLA .NET for Silverlight), I'm going to do a series of posts describing the basic process of creating a CSLA Light application. This first post will provide a high-level overview of the project structure and some concepts. First, it is important to realize that CSLA Light will support three primary physical architectures: a 3-tier (or SOA) model, a 3-tier mobile objects model and a 4-tier mobile objects model. At all times CSLA Light follows the same n-layer logical architecture of CSLA .NET, where the application has the following layers: Presentation/UI Business Data Access Data Storage The primary goal of CSLA Light and CSLA .NET is to support the creation of the Business layer in such a way that the interface points to the Presentation/UI layer and to the Data Access layer are clearly defined. To a small degree, CSLA Light will assist in the creation of the Presentation/UI layer by providing some custom Silverlight controls that solve common issues and reduce UI code. Like CSLA .NET, CSLA Light is not an ORM and does not really care how you talk to your database. It simply defines a set of CRUD operators - locations where you should invoke your Data Access layer to retrieve and update data. 3-Tier or SOA Model If you use CSLA Light in a 3-tier (or SOA) model, your physical tiers are: Silverlight Service Database You can treat these as tiers, or as separate applications where you use SOA concepts for communication between the applications. That's really up to you. In this case the focus of CSLA Light is entirely on the Silverlight tier . In that Silverlight tier, you'll have the following logical layers: Presentation/UI Business Data Access/Service Facade To do this, you configure the CSLA Light data portal to run in local mode and it calls the DataPortal_XYZ methods right there in the Silverlight client tier. You implement the DataPortal_XYZ methods to invoke remote services in the Service tier. CSLA Light doesn't care what those services look like or how they are implemented. They could be asmx, WCF, RSS, JSON, RESTful, SOAP-based - it just doesn't matter. If you can call it from Silverlight, you can use it. The CSLA Light data portal is designed to be asynchronous, because any calls to remote services in Silverlight will be an asynchronous operation. In other words, the data portal is designed to support you as you call these remote services asynchronously. The only requirement is that by the Read More... Posted Monday, July 28, 2008 12:26 PM from Rockford Lhotka | 0 Comments Filed under: Architecture, CSLA .NET, Silverlight

• Prototype Silverlight data portal

  I spent some time over the past few days using my prototype Silverlight serializer to build a prototype Silverlight data portal. It is still fairly far from complete, but at least I've proved out the basic concept and uncovered some interesting side-effects of living in Silverlight. The good news is that the basic concept of the data portal works. Defining objects that physically move between the Silverlight client and a .NET web server is practical, and works in a manner similar to the pure .NET data portal. The bad news is that it can't work exactly like the pure .NET data portal, and the technique does require some manual effort when creating the business assemblies (yes, plural). The approach I'm taking involves having two business assemblies (VS projects) that share many of the same code files. Suppose you want to have a Person object move between the client and server. You need Person in a Silverlight class library and in a .NET class library . This means two projects are required, even if they have the same code file. Visual Studio makes this reasonable, because you can create the file in one project (say the Silverlight class library) and then Add Existing Item and use the Link feature to get that same file included into a .NET class library project. I also make the class be a partial class, so I can add extra code to the .NET class library implementation. The result is: BusinessLibrary.Client (Silverlight class library) -> Person.cs BusinessLibrary.Server (.NET class library) -> Person.cs (linked from BusinessLibrary.Client) -> Person.Server.cs One key thing is that both projects build a file called BusinessLibrary.dll . Also, because Person.cs is a shared file, it obviously has the same namespace. This is all very important, because the serializer requires that the fully qualified type name ("namespace.type,assembly") be the same on client and server. In my case it is "BusinessLibrary.Person,BusinessLibrary". The Person.Server.cs file contains the server-only parts of the Person class - it is just the rest of the partial class. The only catch here is that it can not define any fields because that would obviously confuse the serializer since those fields wouldn't exist on the client. Well, actually it could define fields as long as they were marked as NonSerialized. Of course you could also have a partial Person.Client.cs in the Silverlight class library - though I haven't found a need for that just yet. One thing I'm debating is whether the Read More... Posted Wednesday, April 23, 2008 10:08 AM from Rockford Lhotka | 0 Comments Filed under: Architecture, CSLA .NET, Silverlight