BusinessBase<T> and static property?

BusinessBase<T> and static property?

Old forum URL: forums.lhotka.net/forums/t/7343.aspx


Goran posted on Monday, July 27, 2009

How should we handle static property in BusinessBase<T>? I Have the following scenario

TypeBase : BusinessBase<TypeBase>

TypeA : TypeBase
TypeB : TypeBase

There are some TypeBase.properties that will contain common (static) values, which should be available to all classes that subclass TypeBase, and if one subclass (ex TypeA) of TypeBase changes this property, this change should be available to all other subbclasses also (TypeB, TypeC, etc).

I guess this calls for static property (unless I am unaware of some pattern that can handle this scenario). GetProperty/SetProperty are an instance methods, so they cant be used with static property.

How do we handle static properties with CSLA?

Edit: also using static properties I wont be able to use databinding mechanism. Am I using the correct approach here?

RockfordLhotka replied on Monday, July 27, 2009

You probably want a static value with an instance property.

private static int _value;

public int Value
{
  get { return _value; }
  set { _value = value; }
}

Just remember that if your client code is multi-threaded you'll need to wrap this with locking code, because a static field spans threads.

And remember that if you do this on the server, this static field will not only span threads, but it will span users. It isn't scoped at the user level, it is scoped at the AppDomain level - which essentially means the virtual root.

If you need this to work on the server in a per-user manner, you might consider using Csla.ApplicationContext.LocalContext, which is scoped per-user (and per-client request). On the client, LocalContext is per-thread, so you avoid threading issues in one way, but you must remember that a value set on one thread won't be available to other threads.

(except in Silverlight, where LocalContext is at the AppDomain level because there is no concept of per-thread storage)

Copyright (c) Marimer LLC