N-Tier application with WPF/WCF and CSLA Version: 3.0
Problem Statement: We are having problem in finding the best way for handling and communicating Business Errors. The business errors can occur on client as well as on server. We need a uniform way of handling business errors.
We can not use BrokenRules collections because of Legacy systems complex validation processes which are out side of the entity and they are SET based.
Can we add business errors to GlobalContext so that other calling server side and client side methods can check the GlobalContext for the error key and take action.
Is this Thread safe? If I run 2 instances of my application on the same machine then will both the instances be able to get their own error message without stepping on each other.
The FACT that we have a WPF application, Does that makes a difference of how we access global context?
Please suggest appropriate way of handling such scenario.
Csla.ApplicationContext stores the context data in a per-thread location. So while it is _safe_ in a threaded scenario, it probably won't do what you want - which would be to share values across threads.
WPF, btw, is not intrinsically multi-threaded. The UI elements of WPF are not threadsafe at all, and can only be manipulated by the main UI thread.
If you want to create some global repository for a list of broken rules in a WPF client you might consider hanging the values off the AppDomain. If I remember right, AppDomain has a "Tag" like construct (I don't remember what it is called) where you can put global values.
Obviously you'll have to create some threadsafe container object to manage all your broken rules in a way where they can be accessed and manipulated across multiple threads - no small task, especially if performance matters.
Good luck!
Copyright (c) Marimer LLC