I have a business object library that currently uses a set of ClientContext objects for passing client-side My.Settings values to the server-side code. This works reasonably well. We're about to significantly extend our application to multiple clients and I'm looking at storing a lot of behaviors in a centralized db table. For example, reinforce such-and-such business rule if the particular client has it configured as such. For this to work, I need both the client code and the business objects at server-side to have access to the same set of config data.
Any thoughts on the best way to implement something like this?
Thanks
Hi,
GlobalContext is a 2 way context whereas ClientContext is one-way from client to server. But there are limitations (or requirements for spesial handling) especially if you are using BackgroundWorker or the async DataPortal.You should also keep in mind that data loaded into ClientContext/GlobalContext gives extra overhead on the wire (will be send/received for all server calls).
As for rules - I assume that you will have to create a Rule that loads/accesses configured data in the database and uses RuleChaining to call the actual Rules.
I'd probably recommend to load all the rules config for a client into a cached thread safe dictionary on both the server and client and create your own Rule that will use RuleChaining to call the actual rules. This Rule must be set to run on all fields that are configurable in your app.
Jonny,
Thanks for your input. This is the general direction we've been discussing, although I hadn't known about GlobalContext until now. I think we can use some amount of rule chaining, as you suggest, but there will probably be other behaviors that don't lend themselves to rules. We're thinking that we'll build cached structures on both the client and server sides that will help branch rules, methods, and UI elements. I suspect that it will get fairly complex because of the possible interrelationships between different configuration requirements and that we'll also employ some amount of inheritance to encapsulate broader behavior differences. What we're trying to avoid is using only OO to handle these things; it has seemed to be a bottomless pit of complexity to do things this way.
Thanks again for your input.
Copyright (c) Marimer LLC