Has anyone undertaken to do a kind of gap analysis between the new features of SL3 and CSLALight? Probably a bit early to be asking but it looks like there may be some overlap??
There are some direct similarities, in that they are projecting some elements of the "real" business object from the server into the client. They don't quite go as far as CSLA, where the actual business object is on client and server, but it is close.
On the other hand, they own Visual Studio, and so their integration will certainly be stronger - they do a lot of "magic" in VS and get some pretty cool results. This may irritate some people, who dislike too much magic in their development - it will be interesting to watch feedback over the next few months.
From my perspective, I think it is very interesting, and is a validation of the mobile object ideas I've been pushing for 12+ years. Now Microsoft can catch some of the flak I've dealt with, and perhaps their support of the concept will help generate more buy-in overall :)
From a selfish perspective, I note that RIA Services are "after SL 3" and so are maybe two years away from reality. By that point CSLA .NET for Silverlight 4.x or higher will exist, so in a very real sense they are playing catch-up to CSLA.
And they'll only do SL, while CSLA objects support SL, WPF, Web Forms, ASP.NET MVC, Windows Forms, Workflow, WCF, asmx and console interfaces (maybe more) - all against the same set of business logic.
And they'll probably limit their data access story to one of the Microsoft technologies. I think it unlikely they'll support all the Microsoft data options, much less non-Microsoft ones. CSLA is intentionally agnostic in this regard, and works as well with raw ADO.NET as it does with EF, and I think that flexibility is beneficial.
Then again, Microsoft has amazing resources at its disposal, and so RIA Services could expand to encompass a broader set of CSLA-like concepts if they chose to do that - time will tell.
In the meantime, some of the fallout from RIA Services is ending up in SL 3 - including support for navigation, deep linking and much improved data binding. This means that some of the features we've built to make SL 2 useful can be removed in a future version of CSLA, because they'd be redundant with core SL 3 features. That makes me happy, as it means less stuff to support over time, and that allows me to work on other cool stuff ;)
CSLA .NET for Silverlight supports isolated storage today. If you use the data portal in local mode, your data access methods run on the client workstation, and so can access data via isolated storage or remote service calls or both.
I'm not real interested in writing my own data synchronization engine - which is what is really necessary for good occassionally connected/disconnected application scenarios. I'm personally hoping that SQL CE ends up working on SL at some point, because (presumably) that'd mean you could use Sync Services to sync the client-side and server-side databases.
Today your only real option is to use XML files, or make up your own file format for isolated storage - neither of which is really ideal. And you have to manage your own synchronization with the central database, and that's not fun either.
Just because SL3 will go offline doesn't mean they'll directly address the data sync issue - and so it is beholden on all of us, as users of the technology, to let Microsoft know how important it is that they have a good story for offline data sync in SL3.
Copyright (c) Marimer LLC