CslaLight seems to be more differend.
- We can't use a custom factoryloader anymore, but we gladly don't have to.
- DataMapper is gone.
- DynamicMethods aren't supported.
- So is the MethodCaller missing CallPropertyGetter etc.
MethodCaller.GetProperty and MethodCaller.GetPropertyValue must be used together?
An overloaded GetPropertyValue based on propertyname would be nice to have ;)
I just noticed that system and System can't be used together, even if it's in a data assembly containing objectfactory's.
The data assembly is referencing CslaLight and thus needs the silverlight system reference.
But... PropertyDescripter, TypeDescripter, etc is all part of System.ComponentModel and guess what, that is the non silverlight System :(
An "extension assembly" won't work i guess since references won't be possible.
Silverlight is a different platform from .NET. It is a "subset of .NET", but it is also quite different in many ways.
Because of that reality, CSLA .NET for Silverlight is not the same as CSLA .NET for Windows.
Our primary focus in creating CSLA .NET for Silverlight was to enable an n-tier scenario where you use the data portal to interact with CSLA .NET for Windows on the server side.
We also support client-only scenarios where CSLA .NET for Silverlight runs only on the client, and the data portal invokes client-side methods (DataPortal_XYZ or object factory) that then call remote services (REST, SOAP, raw http, etc).
We didn't put a huge amount of work into making the client-side "data access" story real smooth, because Silverlight is so new. It just isn't clear what (if any) data access or service calling technologies Microsoft might add as Silverlight matures, and it wasn't clear that we could make things simple for this scenario without having our work (and thus your code) become obsolete in a short period of time.
If you are using the object factory model, the ObjectFactory base class in Silverlight should be very comparable to the one in .NET.
Reading your reply "Our primary focus in creating CSLA .NET for Silverlight was to enable an n-tier scenario where you use the data portal to interact with CSLA .NET for Windows on the server side."
It seems u say that the data assembly behind the dataportal for the objectfactory is server-side, but the objectfactory is creating a businessobject.
But yet, too less experience with Silverlight, just diving into it..
ps: dont search in google "what is new in silverlight 3" lol
To be sure: is the data assembly (objectfactory's behind the dataportal)
1) server-side only?
2) server side & client side?
3) client side only?
Even if it's server side, i believe silverlight isn't stateless, will an cached instrance be disposed or just "alive" while the wcf-proxy has a connection?
One BIG problem we got is that our (against WPF) objectfactory's are responsible for constructing & filling a business object. To realise that they must reference to the correct business assembly and in our case a custom business framework assembly.
It isn't possible to reference both Csla and CslaLight in a data assembly, so we're screwed :(
I could avoid using WPF Only classes like the TypeDescripter, but in the end we'll have a situation where we do need to use more powerfull functionality on the server side.
Looking at RemotePortalWithObjectFactory sample i see u include the same business object twice. Is that done by projectlinker or something else?
Silverlight directives...
Ok so it must be possible but i yet don't know how to fit it in our framework layer.
Copyright (c) Marimer LLC