I have done this before. I had a generic NVLB class that
would accept enumeration on GetBlahBlah, the convert the enum to stored
procedure name, and just read first column as ID, second column as name.
Having said that, I do not recommend doing this because it is hard to secure
such asset via authorization rules and you have tight coupling between possibly
unrelated classes.
Sergey Barskiy
Principal Consultant
office: 678.405.0687 |
mobile: 404.388.1899
Magenic ®
Microsoft Worldwide Partner of the Year | Custom
Development Solutions, Technical Innovation
From: abhicbsa
[mailto:cslanet@lhotka.net]
Sent: Tuesday, September 30, 2008 8:08 AM
To: Sergey Barskiy
Subject: [CSLA .NET] Generic NameValueListBase class
Can i create a generic class for fetching (name, value) type
of data.
I have many comboboxes in my pages that i need to populate.
Creating separate classes for every table doesn't make any sense (to me anyway
i may be wrong here).
Should i create only one class where i will pass table name, id column name,
value column name as parameters.
Thanks,
Abhi
"Can i create a generic class for fetching (name, value) type of data."
Yes you can. But should you?
I have done it with similar classes and it works but is not very OO and can get unwieldy over time.
It is recommended that you create separate classes for each. Yes you have more files but stick them all in a folder and hide them. You will probably appreciate it in the long run.
Joe
We did something in between a single generic class and completely separate classes:
1. Most of the functionality is indeed identical (loading data, populating list, etc.), so this is in a common base that derives from NameValueListBase.
2. We did was have our DTO's implement an interface if they want to be "generically" loadable into a NameValueListBase -derived class:
public interface INameValueBase<K, V>{
NameValueListBase<K, V>.NameValuePair ToNameValuePair();}
3. Our DTO's all derive from a common class, so the generic class in (1) can safely access their fetch methods to populate the list. The interface in (2) provides for construction of the data to be stored in the list.
The end result of this is that we do have individual class files for each NVLB class, but they are tiny -- usually just the class declaration.
Here is an example: (ItemType is the DTO that will populate the list, and it's a list of int+string pairs)
[
Serializable()] public class ItemTypeList : WORMapperNameValueListBase<int, string, ItemType, ItemTypeList>{
}
Copyright (c) Marimer LLC