CSLA With Silverlight

CSLA With Silverlight

Old forum URL: forums.lhotka.net/forums/t/7605.aspx

wjcomeaux posted on Thursday, September 10, 2009

Hey guys:

I'm looking through all of the examples available with the lightsamples downloads and I'm trying to figure out what all I need to do with my codesmith templates to output CSLA objects that are consumable by both Silverlight and normal ASP.NET applications.

I am using the latest Codesmith CSLA templates provided by the Codesmith team and I want to customize them for Silverlight. Can someone list what needs to happen to the generated classes?

Is it as simple as wrapping all of the currently generated DataPortal_XYZ functions with #if !SILVERLIGHT and having the templates also generate a set of DataPortal_XYZ methods that silverlight can consume in the #else block?

I've also seen in the demo applications where the constructor is public for Silverlight and I don't quite understand why that would be?

Also, where exactly would a WCF service layer most appropriately fit? I see in the examples that you can use WCF from Silverlight directly or you can use the remote data portal (which may or may not employ WCF services).

Is either method better than the other? Would the remote data portal approach be a better choice considering we want to use the objects in Silverlight and normal Web/Windows applications?

Keep in mind this Silverlight and WCF territory is very new to me so if some of these questions seem overly noobish please be gentle.

Thanks,

Will

RockfordLhotka replied on Thursday, September 10, 2009

The best source of information about CSLA .NET for Silverlight is the video series from http://store.lhotka.net.

Silverlight objects do have some different requirements, including:

  1. Public default constructor (due to Silverlight reflection limitations)
  2. Use of managed backing fields (for serialization - or you must override OnGetState/OnSetState to serialize all your private backing fields manually)
  3. Add a "using Csla.Serialization;" at the top of each class (because Silverlight doesn't have a [Serializable] attribute among other things)
  4. Any non-Silverlight code must be in a separate partial class or in #if !SILVERLIGHT blocks (because that code won't compile for Silverlight)
  5. Every business class needs to be included in two projects: a Silverlight class library and a .NET class library (because the target runtimes are different, and you need to build a Silverlight DLL and a .NET DLL with the same code)

CSLA .NET for Silverlight supports several different architectural configurations, including:

  1. "Edge" application architectures where the data portal runs in local mode, and the client-side DataPortal_XYZ methods invoke remote REST or SOAP services as you choose
  2. 3-tier or 4-tier client/server architectures where the data portal runs in remote mode, talking to a CSLA .NET for Windows application server via WCF - this is comparable to the "normal" usage of CSLA .NET in other environments

There are variations on these themes, with various authentication capabilities and so forth.

wjcomeaux replied on Friday, September 11, 2009

Thanks Rocky.

I'll put pressure on my manager today for the video series. They sounded open enough to do it so maybe I can rush them along.

I appreciate the tips!

Will

Copyright (c) Marimer LLC