Complex taxonomy ORM mapping - looking for suggestions -

in project (asp.net mvc + nhibernate) have entities, lets documents, described set of custom metadata. metadata contained in structure can have multiple tags, categories etc. these terms have importance users seeking document want, has impact on views underlying data structures, database querying etc.

from view side of application, interests me string values terms. ideally operate directly on collections of strings that:

class metadataasseeninviews {     public ilist<string> categories;     public ilist<string> tags;     // etc. } 

from model perspective, use same structure, simplest-possible orm mapping , use in queries "fetch documents metadata this".

but kind of structure turn out useless if application needs perform complex database queries "fetch documents, at least one of categories in (cat1, cat2, ..., catn) or @ least one of tags in (tag1, ..., tagn)". in case, performance reasons, use numeric keys categories , tags.

so 1 can imagine structure opposite metadataasseeninviews operates on numeric keys , provide complex mappings of integers strings , other way round. solution doesn't satisfy me several reasons:

• it smells single responsibility violation, we're dealing database-specific issues when wanting describe document business object
• database keys leaking through layers
• it adds unnecessary complexity in views
• and believe doesn't take advantage of can orm do

ideally have:

• single, simple possible metadata structure (ideally 1 @ top) in whole application
• complex querying issues addressed in database layer (meaning db + orm + @ less possible additional code data layer)

do have ideas how structure code , orm mappings elegant, effective , performant possible?

i have found problematic use domain entities directly in views. decouple things apply 2 different techniques.

most importantly i'm using separate viewmodel classes pass data views. when data corresponds nicely domain model entity, automapper can ease pain of copying data between them, otherwise bit of manual wiring needed. seems lot of work in beginning helps out once project starts growing, , important if haven't designed database scratch. i'm using intermediate service layer obtain viewmodels in order keep controllers lean , able reuse logic.

the second option performance reasons, end creating custom repositories fetching data spans entities. is, create custom class hold data i'm interested in, , write custom linq (or whatever) project result that. can dramatically increase performance on fetching entities , applying projection after data has been retrieved.

let me know if haven't been elaborate enough.