We're looking to build mobile apps (in addition to our existing WinForms app) using Xamarin and our CSLA objects, and we'd like to continue using the mobile object concept (so binding our existing Csla objects to the XAML Xamarin forms).
One thing I'm concerned about though is the server side of the of mobile objects if we make changes to the CSLA object, such as adding or removing a property or even a child object / collection.
We can't force everyone to update at the same time, and it make take time for the app to even be available in the store after its approved. Meanwhile the currently deployed version will need to work, so I'm wondering what the recommendation is to handle this. Deploy a new data portal host site for the new version, while leaving the old one intact? That seems like it would make breaking DB changes more difficult to handle. Somehow handle the differences in code? Any advise would be great!
HI Andy,
Unfortunately I don't have an answer for you since we are just getting started with CSLA.NET but I do have a similar concern since we too are building a Xamarin Forms project and hoped to re-use our business logic which is why we chose CSLA.NET. So if anyone ever answers this, I would be interested in the solution too.
In the meantime, I have a question about sharing the business layer. I didn't realize there were different collection types based around binding support so my question is how do you handle writing one business layer and sharing it between a Winforms client and a Xamarin (mobile) client? It appears to me at least at the surface you can't because you have to choose your collections and what they derive from based on the technology of the client. Do you create multiple collections with similar code deriving from different types when you want to share the business logic on Winforms and something like Xamarin?
Thanks
Mark
Hi Andy,
Unfortunately that is one the drawbacks of using binary serialization. To my knowledge - you need to support all active versions where each version has it's own URI so that you can safely support your clients.
Another good option is to create a REST service on the serverside that supports several versions and use CSLA on client only (edge application).
(This is the typical way I have used CSLA in my applications).
Breaking DB changes is a PITA on any of these approaches.
Just as a sidenote - using CSLA on the client only also allows us to share the backend between WinForms and WPF/SL/Xamarin as the clients may use different base classes depending on the UI to support. There is of course drawbacks to transactional integrity - being limited to one rest call - but I have found this to be manageable.
What about just forcing the user to update the mobile client app? I have been playing Age of Empires on my Wnidows Phone for a while and each time they push out an update and I launch the app, I get a message telling that I need to upgrade and it won't let me continue with the old version. This would solve your problem of having to support multiple versions. :)
This is a problem with any distributed service-based solution where you can't control client-side deployment. In other words, the problem isn't unique to CSLA.
The typical solution is to develop your server code/deployment such that you can run multiple versions of the service at the same time, retiring older versions of the service as your user base ultimately updates to the current client app version.
The most common way to do this is to embed the version number into the URL for the service endpoint, and the easiest thing is to host each endpoint in its own AppDomain (web site). Each client app will talk to the URL corresponding to that client's version.
This is easy to do with the data portal, just like with any other service endpoint, and addresses this issue pretty effectively.
The typical solution is to develop your server code/deployment such that you can run multiple versions of the service at the same time, retiring older versions of the service as your user base ultimately updates to the current client app version.
The most common way to do this is to embed the version number into the URL for the service endpoint, and the easiest thing is to host each endpoint in its own AppDomain (web site). Each client app will talk to the URL corresponding to that client's version.
This is easy to do with the data portal, just like with any other service endpoint, and addresses this issue pretty effectively.
Glad to see you back on the forums! Hope your recovery is going well.
Yes, this issue certainly isn't unique to Csla. Multiple version specific portals sounds like the way to go, and I'm assuming that is the case because that is still easier to maintain / more cost effective than going traditional REST / web service route where the client app and the web service are treated as two separate applications (my experience with that is that its very expensive). Thanks for everyone's feedback.
Copyright (c) Marimer LLC