Стратегии для моделирования большого (50 ~) количества свойств

Question

Сценарий

Я анализирую электронные письма и вставляю их в базу данных, используя ORM (NHibernate, если быть точным). Хотя мой нынешний подход технически работает, я не очень люблю его, но не могу найти лучшего решения. Письмо содержит 50 полей и отправлено от третьей стороны и выглядит следующим образом (очевидно, очень короткий фиктивный образец).

Field #1: Value 1       Field #2: Value 2
Field #3: Value 3       Field #4: Value 4       Field #5: Value 5

Задача

Моя проблема в том, что при разборе стольких полей таблица базы данных становится абсолютным монстром. Я не могу создавать правильные модели, использующие какие-либо отношения, либо AFAIK, потому что каждое отправленное электронное письмо представляет собой все статические данные и не зависит от других источников.

Единственная идея, которая у меня есть, - найти общие черты между каждым полем и разбить их на более управляемые куски. Скажем 10 полей на сущность, итого 5 сущностей. Тем не менее, я не очень люблю эту идею, поскольку вижу, что все, что я буду делать, - это создавать отношения один на один.

Каков хороший способ управления большим количеством свойств, которые находятся вне вашего контроля?

Есть мысли?

Answer 1

Создайте 2 таблицы: одну для основного объекта и другую для полей. Таким образом, вы можете программно обращаться к каждому полю по мере необходимости, и объектная модель не выглядит непривлекательной.

Но это только с моей головы; у тебя странная проблема.

Если данные возвращаются в файл, который вы можете легко проанализировать, то вам, возможно, удастся создать приложение для командной строки, которое будет генерировать скрипты и C #, которые вы затем сможете выполнять и копировать, вставлять в вашу программу , Я сделал это при создании свойств из таблиц из HTML-страниц ( Как этот я должен был сделать недавно )

Answer 2

Если 50 свойств на самом деле являются уникальными и дискретными частями данных, относящимися к этому одному объекту, я не вижу проблемы с наличием этих 50 свойств (даже если это звучит как много) на одном объекте.Например, класс Type имеет большое количество логических свойств, относящихся к его данным (IsPublic и т. Д.).

Альтернативы:

Хорошо, одна опция, которая сразу приходит на ум, - это использование динамического объекта и переопределение TryGetMember для поиска имени «свойства» в качестве ключа в словаре пар значений ключа (где вашсуществует реальная установка из 50 пар ключ-значение).Конечно, выяснение того, как отобразить это из вашего ORM в вашу сущность, является другой проблемой, и вы потеряете поддержку intellisense.

Тем не менее, просто выбросить идею.

Answer 3

Используйте словарь вместо отдельных полей. В базе данных у вас просто есть таблица для имени поля и его значения (и к какому объекту оно принадлежит).