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?
Thanks, until now i didn't know about an CSLA Faq Screwwiki :)
As far as i know i believe we are only using managed backing fields, no problem then ;)
Perhaps we'll have some serializable objects, we'll see soon enough when.
Not using LINQ to CSLA.
How does this work with the dataportal using an ObjectFactory?
Not doing anything special other then reading properties within a business class, which already have been loaded by the objectfactory.
What is differend about the Authentication?
Are the BusinessPrincipalBase & CslaIdentity gone or are they differend?
Only using the UI Component PropertyStatus, i guess it won't be that differend.
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.
- 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).
Copyright (c) Marimer LLC