Feb 8, 2012 at 10:15 PM
Edited Feb 11, 2012 at 12:38 AM
There is some material that can help you better understand Silverlight workings under CSLA:
To make it short, almost everything is the same under Silverlight, except:
- .NET database classes aren't available
- server calls must by asynchronous
- RunLocal attribute doesn't exist
- you have no access to .config files
CslaGenFork doesn't care about 4. So let's forget about it.
Due to 1. all DataPortal methods that use database classes can't run under Silverlight. Most of the times DataPortal_Create doesn't make any database calls so it can run under Silverlight. In this case, the method runs on the client side, it runs locally.
Due to 3. you must use an extra parameter that tells CSLA framework you want to run the code locally. So although asynchronous, Silverlight calls are different from WPF calls sinde the former have an extra parameter.
Due to 2. under Silverlight the factory methods must use asynchronous DataPortal calls.
The #if SILVERLIGHT and #if !SILVERLIGHT conditional compiler directives intend to exclude remote DataPortal methods from the Silverlight client side assembly. They are also used to use or not use the extra parameter on DataPortal_Create. Last, they are
used to exlude synchronous calls from Silverlight client side assembly.
In the usual scenario, on the Silverlight assembly (DLL for you and me) you get only DataPortal_Create methods and no other DataPortal methods. You ask "why on earth am I calling a method that doesn't exist in the Silverlight assembly?".
In fact you never call DataPortal methods directly; you call a CSLA framework method that takes care of invoking the DataPortal method on behalf of the client side assembly. That's exactly what happens when you are running a Silverlight assembly.
So what's different?
Just compare the two paragraphs below:
On a WindowsForms or WPF or Web Forms scenario, the exact same assembly exists on the client and on the server. If you are running the application using a remote DataPortal, when your client assembly calls a DataPortal method, CSLA framework takes care of
using remoting or WCF to relay the call to the server assembly that executes the call (in fact you don't need those methods to be present on the client side assembly).
On a Silverlight scenario, the assemblies on the client and on the server are different, since the former has no DataPortal methods. Your application MUST USE a remote DataPortal. When your client assembly calls a DataPortal method, CSLA framework takes
care of using WCF to relay the call to the server assembly that executes the call (in fact those methods aren't present on the client side assembly).
Note that on every case, relaying execution to the remote server and returning data back to the client is completely transparent (like in invisible) to the developer. One just needs to call the DataPortal method and have the correct configuration; CSLA framework
does all the work for you.
As you can see there are some minor differences but the inner work flow of CSLA framework is basically the same. That the beauty of CSLA. It used to work just like that, long before Silverlight was born. Rocky made some adjustments and voilá, we got
CSLA for Silverlight.
Hope that helps.
Tiago Freitas Leal