Hi,
Having finally started some work with CSLA 3.6 I find myslef having to come to terms clients side code and server code. I was hoping someone could tell me if the follow is correct:
1. When talking about CSLA, then server side code is basically anything that is executed in (or from) the DataPortal_xyz methods.
2. If my BO library is running just on a windows forms client, (i.e. no WCF, Web Services or other server hosting environments) then my 'server side' code also runs on the client.
3. If I host on an application server then it is only the DataPortal that is remoted. My windows forms client still has a copy of the BO's locally, it's just when the object is saved or loaded does my app server get used.
4. If I have data that is retrieved from the Client application, say the locale for the user (this is hypathetical), then in order for the server side code to read it I should put it in either the ClientContext or GlobalContext.
5. If I wanted to create a caching class that contained data that the DataPortal methods needed (could be a connection string that was dependant on some client specific data) then so long as I populate the cache and read from it in the server side code then it would live on the server. It wouldn't typically be available to the client side code.
Hopefully some of these questions will make some sense!!
Regards
Graham
Gravy:
1. When talking about CSLA, then server side code is basically anything that is executed in (or from) the DataPortal_xyz methods.
Right
2. If my BO library is running just on a windows forms client, (i.e. no WCF, Web Services or other server hosting environments) then my 'server side' code also runs on the client.
Right
3. If I host on an application server then it is only the DataPortal that is remoted. My windows forms client still has a copy of the BO's locally, it's just when the object is saved or loaded does my app server get used.
Not exactly. Read chapter 1, which explains this pretty well I think. The whole point of the data portal is that the business objects are mobile - they literally move between client and server.
It is true that, in most apps, the business objects spend a lot of time on the client, and only run on the server when being retrieved or updated.
4. If I have data that is retrieved from the Client application, say the locale for the user (this is hypathetical), then in order for the server side code to read it I should put it in either the ClientContext or GlobalContext.
Global context values should usually go into ClientContext.
Some things, like the user's principal and the user's culture (locale) are automatically managed by CSLA and you don't need to worry about them.
GlobalContext really exists for debug-oriented log/trace scenarios. You can use it for whatever you'd like, but be aware that it is serialized to/from the server and so the more you put into GlobalContext, the more overhead you incur on each data portal call.
5. If I wanted to create a caching class that contained data that the DataPortal methods needed (could be a connection string that was dependant on some client specific data) then so long as I populate the cache and read from it in the server side code then it would live on the server. It wouldn't typically be available to the client side code.
That's true, as long as you don't maintain a reference to that object from any of your business objects. When a business object is serialized, all objects it references (from instance fields) will also be serialized and moved to the client.
If you ensure your cache objects are not marked with the Serializable attribute you won't have to worry about them moving - and if you accidentally keep a reference to the cache object you'll get a nice serialization exception telling you that you have a problem :)
Rocky, thank you.
I feel relived I got most of it right. Onwards and upwards as they say :)
Graham
Copyright (c) Marimer LLC