Is it possible to develop silverlight as desktop when the connection get offline with CSLA 4.0 ?
Thanks in advance.
Jason Law
You mean take the app out of browser and have it continue to function?
Yes, but you'll need to decide how to re-route the server calls to some local handler when the server is unavailable. Given the lack of a client-side database in SL that is harder than would be nice...
To do this you need a custom data portal proxy that calls WcfProxy if online, and LocalProxy if offline - that's easy to write. The hard part is writing the client side data access that'll be invoked when you go offline, and developing a sync process to resync the data with the server when you come back online. All of that is outside the scope of CSLA.
Thanks for the reply, but I am still confuse.
Firstly, yes, I would like to take the app out of browser and have it continue to function when it goes offline.
What I confuse is, in silverlight we consume the CSLA for Silverlight, and in business layer we consume the CSLA for windows. When the app being take out of the browser, will these 2 dll being downloaded to local as well? Would it confuse each other since both also have the same namespace?
Btw, in business layer, the data portal which only valid for server side ( not for silverlight ), will it still run? If I have some extra logic on server side business layer, do I need to duplicate it to the silverlight business layer?
In short, except the custom data portal proxy change, will the normal CSLA Silverlight application work on desktop without any other changes?
Thank you very much!
Language (terminology) becomes very important if we are going to have this conversation. I'll assume you've read chapters 1 and 2 of the Expert 2008 Business Objects book, where the terms "layer" and "tier" are defined very carefully.
The business layer runs on both the SL client and .NET server in a 3-tier or 4-tier deployment. When your app is online it can talk to the server, and so the business layer on SL talks to the business layer on the server through the data portal.
When you go offline, the server is no longer available. So you need to come up with some way for the SL app to run without talking to the server. Usually this means you put the data portal into local mode and store data in isolated storage, because that's the only thing SL can really do on the client. Though I suppose in SL4 now you could prompt the user for a real file into which you'd store the data - but you'd have to prompt them to open and save the data each time they run the app offline - so it might not be an ideal experience.
A third option is to require that the user run IIS on their client machine, and when the app goes offline you'd switch the data portal URL to talk to localhost instead of the real server. That would require some interesting deployment and software update technology (that I think you'd have to create) to keep the client workstation's "offline server" code up to date. But I suspect this could be made to work.
The downside is that you'd have to come up with your own deployment model for the "server" code running on the client. The upside is that you could use SQL Express on the client and Sync Services to keep the client and server databases in sync. That's not trivial of course - but is doable.
Most occasionally connected applications don't work as we're discussing btw. Instead, they always talk to their client-side database (or files), and rely entirely on sync to keep that database in sync with the server database when the app is online. Outlook is an excellent example of this - it interacts only with its local pst or ost files, and relies on sync to interact with POP/SMTP or Exchange.
Thanks Rocky!
Really appreciate your explanation in details.
I have been CSLA fan since VB6, and yes, I do own the Expert 2008 Business Objects book. However, I am not doing any CSLA development nor .Net programming, my company is using its own proprietary language.
Anyway, I am really interested to know how far CSLA can goes with all these new technologies and imagine someday I will use it.
Thank you very much!
Copyright (c) Marimer LLC