Winforms Data Caching

[DylanM]

I've seen a few examples on how to cache data in a WinForms GUI, just after
some thought on the best solution. The data I'm trying to cache will be
generally be small collections of Business Objects (eg Lookup data)

1) Using the Web Cache objects

2) Using AppDomain.CurrentDomain.SetData

3) Using the Caching Application Block

4) Using a static variable \ method & implement a Singleton approach

Any ideas on what offers the best performance with least pitfalls...?

Thanks

[Vadym Stetsyak]

Term "caching" means that you create a store namely cache, where
often-accessed entities are placed.
There are different caching strategies, which depend on data being cached.
Also the important thing is that how do you want to access the data.

The common approach ( and the quickest) will be to create a Hashtable and
use it as a cache store.
However, in .NET 2.0 there is generic dictionary Dictionary<T, K> that can
be used for caching, if your data keys ( identifiers ) are simple types
(boxing will be avoided ).

P.S. The above said is the common approach, but if you have to cache some
specific data then specific cache will presumaply give better performance if
correctly designed.

--
Vadym Stetsyak aka Vadmyst
http://vadmyst.blogspot.com

"DylanM" <Dy****@discussions.microsoft.com> wrote in message
news:54**********************************@microsof t.com...

I've seen a few examples on how to cache data in a WinForms GUI, just
after
some thought on the best solution. The data I'm trying to cache will be
generally be small collections of Business Objects (eg Lookup data)

1) Using the Web Cache objects

2) Using AppDomain.CurrentDomain.SetData

3) Using the Caching Application Block

4) Using a static variable \ method & implement a Singleton approach

Any ideas on what offers the best performance with least pitfalls...?

Thanks

[DylanM]

Thanks for reply.

I basically have lookup data that isn't going to change while the user has
the GUI loaded. Instead of going to the database each time to get this
information, I'm just storing the data in memory and retrieving it from
there.

Since this is lookup data, its a small collection of objects (eg; collection
of 'SalesType' object that is fairly simple, exposes ID \ Description \ Code
fields). I just want to store the entire collection somewhere for easy
retrieval.

I've tested the following code, seems to work OK...

public static ObjectSet SalesTypes
{
get
{
ObjectSet salesTypes;

if (AppDomain.CurrentDomain.GetData("salesTypes") == null)
{
DataTable data = Manager.GetData(typeof(SalesType);
salesTypes= new ObjectSet(typeof(SalesType));

foreach (DataRow dr in data.Rows)
{
SalesType salesType = new SalesType (Convert.ToInt16(dr["st_id_pk"]),
dr["st_description"].ToString());
salesTypes.Add(salesType.ID, salesType);
}

AppDomain.CurrentDomain.SetData("salesTypes", salesTypes);
}
else
{
salesTypes = (ObjectSet) AppDomain.CurrentDomain.GetData("salesTypes");
}

return salesTypes;
}
}

I suppose the same result could be achieved with a static member variable
etc....just wondering how others are approaching this area.

Thanks

"Vadym Stetsyak" wrote:

Term "caching" means that you create a store namely cache, where
often-accessed entities are placed.
There are different caching strategies, which depend on data being cached.
Also the important thing is that how do you want to access the data.

The common approach ( and the quickest) will be to create a Hashtable and
use it as a cache store.
However, in .NET 2.0 there is generic dictionary Dictionary<T, K> that can
be used for caching, if your data keys ( identifiers ) are simple types
(boxing will be avoided ).

P.S. The above said is the common approach, but if you have to cache some
specific data then specific cache will presumaply give better performance if
correctly designed.

--
Vadym Stetsyak aka Vadmyst
http://vadmyst.blogspot.com

[Vadym Stetsyak]

Yes, the result will be the same as long as you use string ids ( keys ).

AppDomain internally uses hashtable to store values, however, I'd recommed
you to use
Hashtable instead of AppDomain.

The reason is that AppDomain contains predefined system entries that are
inserted when the application domain is created. That is if one of your keys
will coincide with the predefined entry - you will get an exception.

If you can guarantee that none of your keys will be from the following set,
then you can use it, however better not. :8-)

Predefined values in AppDomain are:
"APPBASE"
ApplicationBase

"LOADER_OPTIMIZATION"
LoaderOptimization

"APP_CONFIG_FILE"
ConfigurationFile

"DYNAMIC_BASE"
DynamicBase

"DEV_PATH"
(no property)

"APP_NAME"
ApplicationName

"PRIVATE_BINPATH"
PrivateBinPath

"BINPATH_PROBE_ONLY"
PrivateBinPathProbe

"SHADOW_COPY_DIRS"
ShadowCopyDirectories

"FORCE_CACHE_INSTALL"
ShadowCopyFiles

"CACHE_BASE"
CachePath

--
Vadym Stetsyak aka Vadmyst
http://vadmyst.blogspot.com

[DylanM]

Thanks Vadym - I'll give that a go!

"Vadym Stetsyak" wrote:

Yes, the result will be the same as long as you use string ids ( keys ).

AppDomain internally uses hashtable to store values, however, I'd recommed
you to use
Hashtable instead of AppDomain.

The reason is that AppDomain contains predefined system entries that are
inserted when the application domain is created. That is if one of your keys
will coincide with the predefined entry - you will get an exception.

If you can guarantee that none of your keys will be from the following set,
then you can use it, however better not. :8-)

Predefined values in AppDomain are:
"APPBASE"
ApplicationBase

"LOADER_OPTIMIZATION"
LoaderOptimization

"APP_CONFIG_FILE"
ConfigurationFile

"DYNAMIC_BASE"
DynamicBase

"DEV_PATH"
(no property)

"APP_NAME"
ApplicationName

"PRIVATE_BINPATH"
PrivateBinPath

"BINPATH_PROBE_ONLY"
PrivateBinPathProbe

"SHADOW_COPY_DIRS"
ShadowCopyDirectories

"FORCE_CACHE_INSTALL"
ShadowCopyFiles

"CACHE_BASE"
CachePath

--
Vadym Stetsyak aka Vadmyst
http://vadmyst.blogspot.com