Hello,
A common pattern that I encounter deals with Lookup tables that
provide a string based key for a value. For example one common use of
this is when dealing with Name Value Pairs for settings. So we might
have for example:
Table Setting:
---------------
SettingID int PK
SettingKey nvarchar UK
DefaultValue etc...
Then we might have an association table, in some cases this might just
be a pure association entity or it may contain extra information about
the association as this example will.
UserSetting
---------------
Id guid PK
SettingId FK
UserId FK
SettingValue
What I wanted to do is map this to my objects so that I can use a
dictionary, and that the key would be SettingKey. I've not found a
clean way to do. And I am wondering if anyone has faced this problem
and how they solved it. My solution is not optimal but it is
functional.
Essentially we had the following classes:
class user
{
Dictionary<string,Setting> Settings;
}
class Setting
{
string Value;
SettingDefinition Defnition;
string Key;
}
What I did was I mapped this as an idBag to a private property on my
UserObject. I then subclassed a dictionary<key,val>, which ensures any
changes to the dictionary is made to the idBag. I'm not a fan of this
because it leaked the persistance layer into my domain logic (however,
since it didn't affect the application tier I was willing to let this
one through).
It'd be neat if a map element could pull the index from a joined
table. My other solution which I really wasn't a fan of and am going
to go back and change shortly was to create a view which joined the
two tables, and then I used the view as the table. My issue with this
approach was that I was now maintaining data access logic (The view
required triggers to make sure I could update the underlying table).
I'm curious what peoples thoughts are on this.
Thanks,
Josh
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"nhusers" group.
To post to this group, send email to [email protected]
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/nhusers?hl=en
-~----------~----~----~----~------~----~------~--~---
