Hi All,
we want to save data from the same business objects (same types) into two locations.
We have read all kind of things on changing the Proxy and data portals, but we don't feel we have found a concrete solution to our problem.
Is there a way to dynamically set the WCF endpoint to save a business object into one server and afterwards to another server by changing the endpoint.
If we look a the proxy you can only switch on the type of object. This means we have to start inheritance of all our objects.
Thanks in advance.
Jim
There are two general solutions in a 3-tier deployment.
You can create a custom client-side proxy that uses some mechanism to determine which app server to invoke.
Or you can always invoke one app server, and have that app server update the appropriate database - switching database connections based on some mechanism that is purely server-side.
The second approach is often simpler, but obviously is only useful if there's one data center with multiple databases. If you need to communicate with different data centers then the first approach is probably the way to go.
When you create your custom client-side proxy, you can have it decide to invoke different app servers using whatever technique you'd like. This could be inheritance, attributes, ClientContext, LocalContext, the current user principal object or some app-wide static property. The options are endless. All that is required is that you can write some logic in your proxy that determines which app server to invoke.
The most common scenario I'm aware of is to select the app server based on some value stored (usually) in ClientContext. Often this is a value indicating the user's department or division or something like that - a value that is determined once the user has logged into the system.
Creating this custom proxy is not hard if you are using WCF - just subclass the existing WcfProxy class and change the server URL based on your decision logic.
Rocky,
we need the custom client-side proxy solution.
We have only one big question with your proposed solution.
If we set a global var to identify the endpoint we want to use for th save / delete / create or fetch operation, we can have thread safety problems.
Especially with silverlight asynchronous calls.
If we start a save for one object of a type to one datastore and another save of the same type to another datastore, the global identfier can be changed before the first save reaches the proxy.
We were thinking about a solution to pass the endpoint information in our save / update /delete and fetch routines in our business objects.
The disadvantage of this approach is that we need to change some DataPortal classes of CSLA and all the interfaces of our Business objects.
Or do you have a thread safe solution above which doesn't imply so much changes in the core CSLA code.
Thanks in advance,
Jim
If your selection criteria is per object instance, then it is per object instance.
I've said this so many times I can't count - it is always a good practice to create a set of custom base classes that sit between the CSLA base classes and your business classes. This is the primary extensibility model for several aspects of CSLA, including things like business rules, validation rules, authorization and the data portal.
Making such a change is really quite trivial. Create 6 base classes, then change your business classes to inherit from your base classes.
Then enhance/extend functionality as necessary by adding code to the base classes. In your case you will need to define and implement some non-generic interface that your data portal proxy can use to determine the context of the object for the purpose of switching to the right app server URL.
Copyright (c) Marimer LLC