This project has moved. For the latest updates, please go here.

silverlight directive

Feb 8, 2012 at 10:21 AM
Edited Feb 8, 2012 at 10:23 AM

I'm a little confused over the silverlight directive - this is code generated from latest templates

#if !SILVERLIGHT

        /// <summary>
        /// Factory method. Creates a new <see cref="School"/> object.
        /// </summary>
        /// <returns>A reference to the created <see cref="School"/> object.</returns>
        public static School NewSchool()
        {
            return DataPortal.Create<School>();
        }

        /// <summary>
        /// Factory method. Asynchronously creates a new <see cref="School"/> object.
        /// </summary>
        /// <param name="callback">The completion callback method.</param>
        public static void NewSchool(EventHandler<DataPortalResult<School>> callback)
        {
            DataPortal.BeginCreate<School>(callback);
        }

        /// <summary>
        /// Factory method. Loads a <see cref="School"/> object, based on given parameters.
        /// </summary>
        /// <param name="schoolID">The SchoolID parameter of the School to fetch.</param>
        /// <returns>A reference to the fetched <see cref="School"/> object.</returns>
        public static School GetSchool(string schoolID)
        {
            return DataPortal.Fetch<School>(schoolID);
        }

        /// <summary>
        /// Factory method. Marks the <see cref="School"/> object for deletion.
        /// The object will be deleted as part of the next save operation.
        /// </summary>
        /// <param name="schoolID">The SchoolID of the School to delete.</param>
        public static void DeleteSchool(string schoolID)
        {
            DataPortal.Delete<School>(schoolID);
        }

#else

        /// <summary>
        /// Factory method. Asynchronously creates a new <see cref="School"/> object.
        /// </summary>
        /// <param name="callback">The completion callback method.</param>
        public static void NewSchool(EventHandler<DataPortalResult<School>> callback)
        {
            DataPortal.BeginCreate<School>(callback, DataPortal.ProxyModes.LocalOnly);
        }

#endif

        /// <summary>
        /// Factory method. Asynchronously loads a <see cref="School"/> object, based on given parameters.
        /// </summary>
        /// <param name="schoolID">The SchoolID parameter of the School to fetch.</param>
        /// <param name="callback">The completion callback method.</param>
        public static void GetSchool(string schoolID, EventHandler<DataPortalResult<School>> callback)
        {
            DataPortal.BeginFetch<School>(schoolID, callback);
        }

             /// <summary>
        /// Factory method. Asynchronously marks the <see cref="School"/> object for deletion.
        /// The object will be deleted as part of the next save operation.
        /// </summary>
        /// <param name="schoolID">The SchoolID of the School to delete.</param>
        /// <param name="callback">The completion callback method.</param>
        public static void DeleteSchool(string schoolID, EventHandler<DataPortalResult<School>> callback)
        {
            DataPortal.BeginDelete<School>(schoolID, callback);
        }

Why doesn't the last two methods fall in the 'else' (i.e. !SILVERLIGHT) statement as they are asyn silverlight calls?

Also why is this in the !SILVERLIGHT region ( there are three NewSchool methods in total 2 in !SL and one in SL directive)

 public static void NewSchool(EventHandler<DataPortalResult<School>> callback)
        {
            DataPortal.BeginCreate<School>(callback);
        }

What am I missing in my understanding or is this a mistake?

Richard

 

Coordinator
Feb 8, 2012 at 11:15 PM
Edited Feb 11, 2012 at 1:38 AM

Hi Richard,

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:

  1. .NET database classes aren't available
  2. server calls must by asynchronous
  3. RunLocal attribute doesn't exist
  4. 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

Coordinator
Feb 8, 2012 at 11:39 PM
Edited Feb 8, 2012 at 11:43 PM

Hi again Richard,

I just read the CSLA.NET forum thread.

I chose not to mention the public property info in order to stick to your question. There are other public visibility requisites for Silverlight code. Read more about it the Technical Note: Silverlight code for CSLA 4

Feb 9, 2012 at 10:10 AM

Thanks for the full reply.  I will read and digest.