What are the best practices in providing lookup values?

What are the best practices in providing lookup values?

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


superkuton posted on Saturday, June 27, 2009

hello!

I am new to CSLA.NET. Right now, I am creating a simple application to learn how to use the framework.

I have a Person.Profile table with columns like
As you can see, these columns will need several lookup tables.
What are the best practices in providing lookup values in a scenario like this?

RockfordLhotka replied on Sunday, June 28, 2009

You should look at the NameValueListBase class. I recommend reading at least chapters 1-5 and 17-18 of the Expert 2008 Business Objects book to get a solid understanding of the framework and the basics of how to use it.

superkuton replied on Sunday, June 28, 2009

Thanks, Rocky. Yap, I have read the chapters, and I understand how to use the NameValueListBase class.

In my simple case then, I will be creating the Person Object, and 11 NameValueList Objects (one for each lookup value).

Will this be an efficient strategy/technique? Won't this cause several round trips to the server?

In my previous ado.net projects, I create or check for the existence of an XML file which I load as a dataset at runtime. This dataset will then serve as a source of the datatables=>binding source for the lookup values.

Do we have a similar implementation using CSLA? Or is there a better option?

Thanks, Rocky.

RockfordLhotka replied on Sunday, June 28, 2009

A couple things.

 

First, I tend to cache NVL objects in static fields (for a smart client), so I really only get them once in most cases. Obviously there are exceptions for volatile data, but usually this is a big help.

 

Second, if I know that I am going to need a set of NVL objects for a given user scenario, I’ll often create a separate ReadOnlyBase subclass that has the sole responsibility of retrieving the NVL objects. Something like this:

 

[Serializable]

public class LookupListRetriever : ReadOnlyBase<LookupListRetreiver>

{

  public Categories Categories { get; private set; }

  public States States { get; private set; }

 

  public static LookupListRetriever GetData()

  {

    var obj = DataPortal.Fetch<LookupListRetriever>();

    Categories.SetCache(this.Categories);

    States.SetCache(this.States);

  }

 

  private void DataPortal_Fetch()

  {

    this.Categories = Categories.GetList();

    this.States = States.GetList();

  }

}

 

This avoids the round-trips. Notice that the factory forces a load of the static caches for each NVL type. You may have different techniques for caching – just remember that the DataPortal_Fetch() method runs on the server, so something needs to update the client-side cache once the DataPortal.Fetch() call is complete.

 

Rocky

 

RockfordLhotka replied on Sunday, June 28, 2009

A couple things.

 

First, I tend to cache NVL objects in static fields (for a smart client), so I really only get them once in most cases. Obviously there are exceptions for volatile data, but usually this is a big help.

 

Second, if I know that I am going to need a set of NVL objects for a given user scenario, I’ll often create a separate ReadOnlyBase subclass that has the sole responsibility of retrieving the NVL objects. Something like this:

 

[Serializable]

public class LookupListRetriever : ReadOnlyBase<LookupListRetreiver>

{

  public Categories Categories { get; private set; }

  public States States { get; private set; }

 

  public static LookupListRetriever GetData()

  {

    var obj = DataPortal.Fetch<LookupListRetriever>();

    Categories.SetCache(this.Categories);

    States.SetCache(this.States);

  }

 

  private void DataPortal_Fetch()

  {

    this.Categories = Categories.GetList();

    this.States = States.GetList();

  }

}

 

This avoids the round-trips. Notice that the factory forces a load of the static caches for each NVL type. You may have different techniques for caching – just remember that the DataPortal_Fetch() method runs on the server, so something needs to update the client-side cache once the DataPortal.Fetch() call is complete.

 

Rocky

 

superkuton replied on Tuesday, June 30, 2009

how do you use the LookupListRetriever in the win forms (loading, binding, etc.)?

thanks a lot.

superkuton replied on Thursday, July 02, 2009

Rocky,

I understand how to use the lookupretriver but how do i 'setcache' ?

Thanks.

RockfordLhotka replied on Friday, July 03, 2009

You’ll need to implement static SetCache() methods on your NVL classes.

 

Rocky

superkuton replied on Friday, July 03, 2009

How do i accomplish that? Any light/easy example or link to do 'SetCache'?
Can anybody provide a sample NVL object that uses setcache?


Thanks.

RockfordLhotka replied on Monday, July 06, 2009

public class MyList : NameValueListBase<…>

{

  private static MyList _cache;

  public static void SetCache(MyList obj)

  {

    _cache = obj;

  }

}

 

From: superkuton [mailto:cslanet@lhotka.net]
Sent: Friday, July 03, 2009 10:32 AM
To: rocky@lhotka.net
Subject: Re: [CSLA .NET] RE: RE: What are the best practices in providing lookup values?

 

How do i accomplish that? Any light/easy example or link to do 'SetCache'?

Thanks.


superkuton replied on Saturday, August 01, 2009

Thanks, Rocky.

I finally made an implementation of it in a simple application I am working on.

At the app start-up/initialization, I am 'caching' the lookup values. But now I have the following concerns:

1.  It takes some some time to cache the values from the server.

2.  The values are cached from the server each time the application is opened or started.

Are there ways to improve the caching up of lookup values?

I am thinking of a dataset/datatable technique of storing the values in an xml file. When the app is started the values are loaded from the xml file in the client, avoiding the fetching from the server. When the values are altered, an 'invalidate' pattern is employed.

Can we store the values in the client in a similar technique?

Vinodonly replied on Sunday, August 02, 2009

I created this long ago which does the same thing..

http://www.universalthread.com/ViewPageArticle.aspx?Session=415747326476515A5455343D202B4A31507762596B5055516A5A78734A73614D656D513D3D

http://www.universalthread.com/ViewPageArticle.aspx?Session=4F5847576B4A6652486C733D2037645241674E554234476C5054664F306473575135513D3D

After this I hv done many changes like at form startup values are auto catched (when user requests for adding for fetching records)..

At form closeup values are auto cleared..

Controls like comboboxes, text controls, lists etc. are auto filled..

and most imp i switched from vb to c# :)

Copyright (c) Marimer LLC