В моем проекте (ASP.NET MVC + NHibernate) у меня есть все мои сущности, скажем, Document s, описанные набором пользовательских метаданных. Метаданные содержатся в структуре, которая может иметь несколько тегов, категорий и т. Д. Эти термины имеют наибольшее значение для пользователей, ищущих нужный документ, поэтому они влияют на представления, а также на базовые структуры данных, запросы к базе данных и т. Д.
С точки зрения приложения, меня больше всего интересуют строковые значения для терминов. В идеале я хотел бы работать непосредственно с коллекциями строк следующим образом:
class MetadataAsSeenInViews
{
public IList<string> Categories;
public IList<string> Tags;
// etc.
}
С точки зрения модели, я мог бы использовать ту же структуру, сделать максимально простое сопоставление ORM и использовать его в запросах типа «получить все документы с метаданными точно так же, как это».
Но такая структура может оказаться бесполезной, если приложению необходимо выполнить сложные запросы к базе данных, такие как «получить все документы, для которых , по крайней мере, одна категорий равна IN (cat1, cat2, ..., catN) ИЛИ, по крайней мере, один тегов равен IN (tag1, ..., tagN) ". В этом случае по соображениям производительности мы, вероятно, будем использовать цифровые клавиши для категорий и тегов.
Таким образом, можно представить структуру, противоположную MetadataAsSeenInViews, которая работает с числовыми ключами и обеспечивает сложные отображения целых чисел в строки и наоборот. Но это решение меня не устраивает по нескольким причинам:
- пахнет как нарушение единственной ответственности, поскольку мы имеем дело с проблемами, связанными с базой данных, когда просто хотим описать
Document бизнес-объект
- ключи базы данных просачиваются через все слои
- добавляет ненужные сложности в представления
- и я считаю, что это не использует то, что может сделать хороший ORM
В идеале я хотел бы иметь:
- единичная, как можно более простая структура метаданных (в идеале, подобная той, что вверху) во всем приложении
- сложные проблемы запросов, решаемые только на уровне базы данных (имеется в виду DB + ORM + при минимально возможном дополнительном коде для уровня данных)
Есть ли у вас какие-либо идеи о том, как структурировать код и сделать ли сопоставления ORM настолько элегантными, эффективными и настолько производительными, насколько это возможно?