Hi folks,
Has anybody ever implemented or thought about a scenario where they do per-object type or per-location/user descisions whether to instantiate an object locally or remotely.
Mostly I use locally instantiated objects but I have some cases where I need a specific instance to be instantiated remotely. This is usually performance, etc. related. When I do this at the moment I simply activate the objects myself via a config.
But what I was wondering is if there is any pattern out there for tweaking which objects, in which scenarios get instantiated locally and which remotely.
My understanding of clsa is that you choose one or the other - either the entire business layer is instantiated remotely or it is instantiated locally (leaving the [runlocal] attribute out to avoid confusion). I admit my understanding may be very dated.
Thank you
There's an entry in the FAQ about having multiple configurations for the data portal
http://www.lhotka.net/cslanet/faq/DataPortalFaq.ashx
That should answer your question.
Thanks Rocky. It certainly answers part of.
I did something just like this that required a slight modification of CSLA. Basically, CSLA is already designed to let you force methods to run locally even when using a remote portal, so it was fairly simple to extend this to allow operations on entire classes to be forced locally.
The details (and code) are in this thread: http://forums.lhotka.net/forums/p/6085/29512.aspx#29512
I think you can do that force-local thing now using an IDataPortalProxyFactory implementation - avoiding the need to alter CSLA.
Again, thanks for taking time out to respond. I'm happy now that a solution is achievable and that the idea isn't a no-no.
I think you can do that force-local thing now using an IDataPortalProxyFactory implementation - avoiding the need to alter CSLA.
Is this new in CSLA 4.0? I see IDataPortalProxy in 3.8 but not IDataPortalProxyFactory.
It might be new in CSLA 4 - good point.
Copyright (c) Marimer LLC