Hi Rocky,
Do you have plan to include a Silverlight version of ProjectTracker?
Thanks
There are two types of Silverlight app possible.
One is a "thin client" that rests on top of a set of server-side services, so the CSLA objects reside only on the server. Once Silverlight has at least a TextBox control something like that becomes quite possible.
However, full CSLA won't work in Silverlight on the client. Silverlight's sandbox is too restrictive - no private reflection, hence no serialization, so no n-level undo and no data portal as we know it.
I have done some preliminary research though, along the idea of a "CSLA Light" - a version of CSLA that provides things like validation and perhaps authorization, along with n-level undo done without reflection.
So the second type of Silverlight app that may be possible, with CSLA Light, would have business objects running on the client. Different ones from those on the server to be sure, but still quite similar, and providing many of the same UI-support benefits you get from CSLA .NET itself.
All this is speculation of course. Until Silverlight has at least a TextBox and a Button (it has neither today) it is pretty hard to write anything resembling a business application ![Smile [:)]](/emoticons/emotion-1.gif)
Hi Rocky,
Thanks for your speedy response.
My idea is to run the ProjectTracker client under IE, in the same time, it should leverage WPF's righ multimedia function. Is possible to write XBAP (XMAL Browser Application) using CSLA?
Thanks
Technically it is possible to write an XBAP app using CSLA.
However, you’ll encounter security issues, because XBAP apps don’t
run with FullTrust. I’m not sure if you can get them to run with
FullTrust – but that’d be a requirement…
The reason is that CSLA uses a bunch of .NET technologies like
Remoting, WCF, WF, the BinaryFormatter and reflection – all of which
require FullTrust (or close).
This “CSLA Light” I mentioned would avoid using any
of those technologies – which seriously limits or removes some CSLA
features.
The real challenge is that without serialization (both
BinaryFormatter and NetDataContractSerializer require FullTrust) it is
impossible to implement the data portal, in its current form anyway.
If NDCS were to work in partial trust that’d solve the
issue, but I don’t know that Microsoft has plans in that regard, so I
think we’re stuck.
What this means, is that XBAP and Silverlight apps must be built
using an SOA mindset, not a client/server or n-tier mindset. You must view the
client application (XBAP or Silverlight) as a separate application from
the server application that exposes a set of services (via asmx, because it
works in partial trust).
You can use CSLA .NET to build the server application as
described in Chapter 11.
If and when a CSLA Light exists, you’d be able to use that
to create a totally separate application that would run on the client in
XBAP or Silverlight.
As with all SOA models, you’ll end up writing the same
business logic twice in many cases. That’s the price of doing SOA. But at
least you’ll have a low-impact app that is still very rich and
interactive on the client. And you’ll have a powerful and complete app
running on the server, exposed via an XML interface.
Rocky
Hi Rocky,
Thanks for your detail explanation. By the way, is there any plan for CSLA Light?
Thanks
Define "plan" :)
Right now it is a research project, and will remain so until Silverlight is mature enough that we know what is, and is not, possible in that environment.
Copyright (c) Marimer LLC