What to do when going from "CSLA for WPF" to "CSLA for Silverlight"

Reply

rfcdejong Posted: Thu, Jun 4 2009 9:22 AM

rated by 0 users

We are one of many who starts with an WPF application and then want to support Silverlight as well. As i did read on Rocky's blog, it's better to start building for Silverlight, but we did it the other way around.

Today i had some discussions about making a turn to silverlight.

Currently we are using the CSLA framework (with object factory etc) and an own abstraction layer on top of it, in the frontend we have the Composite Application Guidance framework which already has a tool called "ProjectLinker", which links the modules, controllers, presenters and commands etc.. but we still need to write 2 views, an xaml for wpf and a silverlight counterpart.

CSLA and CSLA Light are nearly the same? Is it thru that only LINQ to CSLA isn't supported? Missing the C5 stuff (and warnings lol)

Is there something more to think about related to CSLA when going to CSLA for Silverlight?

Reply

rfcdejong replied on Fri, Jun 5 2009 4:24 AM

rated by 0 users

Thanks, until now i didn't know about an CSLA Faq Screwwiki :)

• Serialization is different, and so you really want to use managed backing fields - otherwise you'll have to do a lot of work to manually serialize/deserialize all your private fields. If you have any private fields in your classes, you have work to do.

As far as i know i believe we are only using managed backing fields, no problem then ;)

• Serialization is different, and so if you have any Serializable objects that don't inherit from a CSLA base class you'll have to make them inherit from one of the Csla.Core serializable base classes (like MobileObject) or manually implement IMobileObject (which is a pain).

Perhaps we'll have some serializable objects, we'll see soon enough when.

• LINQ to CSLA is not implemented in Silverlight, so if you rely on the LinqBindingList behaviors you'll need to work around that in the Silverlight side. I can't say when L2C will exist in Silverlight.

Not using LINQ to CSLA.

• All data access (data portal usage) is async. This will impact all your factory methods, but not your data access methods.

How does this work with the dataportal using an ObjectFactory?

• All server interacts are async. This will impact any business or validation rules that talk to the server (via a Command object, etc). These rule methods need to be rewritten to be async rule methods for Silverlight - which is not usually a huge change, but does take some work.

Not doing anything special other then reading properties within a business class, which already have been loaded by the objectfactory.

• Authentication is different, though we tried to mirror most of the .NET concepts. The good news is that authorization is the same.

What is differend about the Authentication? 
Are the BusinessPrincipalBase & CslaIdentity gone or are they differend?

• In 3.6 the XAML UI components are unique to Silverlight. In 3.7 I expect they'll be a lot more like the WPF components because Silverlight 3 has element binding.

Only using the UI Component PropertyStatus, i guess it won't be that differend.

Reply

RockfordLhotka replied on Fri, Jun 5 2009 9:05 AM

rated by 0 users

rfcdejong:

• All data access (data portal usage) is async. This will impact all your factory methods, but not your data access methods.

How does this work with the dataportal using an ObjectFactory?

It works fine with the ObjectFactory or DataPortal_XYZ models. 

The static factory methods are different in two ways. First, they must include a callback parameter so the UI can provide a callback method that the factory can invoke when the async operation completes - otherwise the UI would have no way of knowing when the operation is done.

Second, the factory must use DataPortal<T>, instead of DataPortal. So instead of one line of code in the factory, you typically have three.

But ultimately the data portal invokes the same code on the server that it would in any other setting.

rfcdejong:

• Authentication is different, though we tried to mirror most of the .NET concepts. The good news is that authorization is the same.

What is differend about the Authentication? 
Are the BusinessPrincipalBase & CslaIdentity gone or are they differend?

Those types still exist and are useful for custom authn. Though of course you have to load them in an async manner, which has some impact.

But SL has no authentication model of its own. So we created WindowsIdentity, MembershipIdentity and some other principal/identity types to create our own model that echos the server model.

As an example: remember that SL might be running on a Mac, so there's no automatic Windows identity like there is for all .NET apps. So we enable a scenario where the client can ask the server for the user's Windows identity, allowing the SL code to get a "simulated" Windows principal/identity.

I'm just wrapping up video segment 7, which covers the basics of Windows, Membership and custom authentication in Silverlight, along with an overview of the authorization model - though that is consistent with the .NET side (per-type and per-property authz works the same).