Должен ли я удалять FK из моей модели домена?

Question

Я начинаю новый проект и планирую использовать nhibernate. Я борюсь с тем, должен ли я держать мою модель домена в чистоте информации о сохранении, оставляя внешние ключи. Я чувствую, что некоторые из моих «моделей» действительно не нужны, и эта производительность будет проблемой. Например:

В моей БД у меня есть следующая таблица:

Posting 
    Id 
    StatusId 
    ... 

Который имеет отношение FK с этой таблицей:

PostingStatus 
    Id 
    Name 

В моей модели я определил 2 класса:

class Posting 
{ 
    virtual int Id { get; set; } 
    virtual PostingStatus Status { get; set; } 
    // .. 
} 

class PostingStatus 
{ 
    virtual int Id { get; set; } 
    virtual string Name { get; set; } 
} 

Имеет ли PostingStatus в моей модели? и в тех случаях, когда я знаю FK раньше времени, например, обновление публикации после отправки, не является ли это довольно тяжелым успехом (или просто бесполезной работой), чтобы nhibernate извлекал экземпляр PostingStatus вместо установки FK?

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

Answer 1

Если для модели домена требуется, чтобы отношения были соблюдены, вам нужны внешние ключи.

Не беспокойтесь о производительности, пока у вас не возникнет проблема с производительностью.

Answer 2

Что сказал Митч. NHibernate собрали люди, которые тщательно изучили эти проблемы. Делайте все правильно, беспокойтесь о оптимизации, когда и если у вас есть проблема.

(NHibernate, вероятно, будет Извлечение проводки sttaus из кэша, в любом случае.)

Кроме того, NHibernate, в зависимости от того, как вы установите его, возможно, потребуется FK ограничений для отображения базы данных для ваших объектов.

Если PostingStatus является объектом домена, вы должны сохранить его. Если это не так, удалите его по этой причине, а не в попытке преждевременной оптимизации.

Answer 3

В этом очень специальном случае вы можете фактически заменить объект PostingStatus Enum. Если вы правильно укажете значения для своего перечисления, они могут сопоставляться с таблицей и выполняться FK.

И NH не будет «просто кэшировать» вещи. Я бы предложил использовать кеш второго уровня с ленивой загрузкой PostingStatus для таких ситуаций.