This article discusses the treatment of data in large C# software applications. More specifically, it discusses runtime data encapsulation, behavior-only encapsulation, and treatment of state.
This article is published at the .NET Curry magazine, click here to read the article.
Hi Yacoub,
Great read :).
I was wondering it one can use the state holder pattern even with operations that involve multiple threads.
we have a scenario where we collect source document processing requests and process them in parallel for each.
Each processing unit needs to now who is the source that invoked it, so it can acknowledge successful process at the end of the work.
Is there a best practice here?
Hello Eliran,
Thanks for reading the article.
The state holder is just a pattern. You can for sure implement it in a way that is thread safe. For example, you can create a decorator that synchronizes access (e.g. via the lock statement in C#) to the decorated state holder.
Or maybe you want each thread to have its own state? Then you create a state holder that stores the state in thread local storage. See the ThreadStatic attribute for example: https://msdn.microsoft.com/en-us/library/system.threadstaticattribute(v=vs.110).aspx
Or maybe you want to read and write state in an atomic fashion? Then you need an IStateUpdater. Something like this:
public interface IStateUpdatert< T>
{
void UpdateState(Func< T,T> updateFunction);
}
With an implementation that synchronizes access to the UpdateState method.
Regarding your second question, I cannot give you an answer without more details about the problem.
Yacoub