Использование ORM, таких как NHibernate, когда есть много ассоциаций - проблемы производительности - PullRequest
0 голосов
/ 11 апреля 2009

Я создал приложение (веб-приложение), которое теперь имеет большое количество ассоциаций. Проще говоря, аккаунт:

  • имеет много пользователей
  • имеет настройки
  • имеет много проектов

Аналогично проекту:

  • имеет много предметов

A Пользователь:

  • имеет много задач

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

Но правильный ли это подход? При каждом запросе к приложению Учетная запись загружается (поскольку она необходима), а затем запрашивает большой объем данных из БД, который не требуется. Ленивая загрузка - вариант, но я не знаю, мог ли мой начальный подход быть лучше. Все, что мне нужно на этом этапе, - это учетная запись и связанные с ней настройки, поэтому должно ли это отображать отображение? Проблема в том, что я хочу, чтобы такие вещи, как все проекты для учетной записи, были в других точках, поэтому мне нужно, чтобы картографы отражали все ассоциации.

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

Ответы [ 3 ]

0 голосов
/ 11 апреля 2009

Domain Driven Design очень помог мне в понимании подобных ситуаций. Ассоциация в ДДД

Вопрос, который вы должны задать себе в вашей ситуации: действительно ли вам нужна двунаправленная ассоциация, или в некоторых случаях может быть достаточно однонаправленной ассоциации? И это решение является частью архитектуры. Значит ты был прав. Lazy Loading очень помогает при выборе двунаправленных ассоциаций по умолчанию. Но это можно считать недостатком дизайна.

0 голосов
/ 11 апреля 2009

Ну, по моему мнению, ваша архитектура выглядит здоровой. Ассоциации хороши.

Рассмотрим альтернативы:

  1. Меньше ассоциаций: приведет к плохому дизайну БД
  2. Не используйте ORM: вы все равно будете выполнять "ленивую инициализацию" - все равно кодирование

Все выглядит хорошо, и ленивая инициализация хороша :) - Тем не менее, в реальной жизни довольно много подводных камней:

  1. Не закрывайте сеанс перед использованием ленивой инициализации (для этого потребуется, чтобы вы взломали какое-то бесполезное утверждение чтения в вашей ассоциации, чтобы заставить его прочитать)
  2. С NHibernate вам нужно выполнить все DAL-действия с ним, чтобы включить кэш уровня 2
  3. У вас наверняка будут некоторые накладные расходы (что если я не хочу знать имя учетной записи, только пользователей в ней)

Вот как работают ORM. У них есть плюсы (легче разрабатывать, избегать много стандартного кода) и минусы (больше накладных расходов, меньше гибкости).

0 голосов
/ 11 апреля 2009

Обычно в NHibernate рекомендуется включать отложенную загрузку для большинства ассоциаций и объектов по умолчанию, если только вы не знаете, что вам всегда будут нужны связанные данные. Затем вы можете переключиться на активную загрузку выборочно только для элементов, которые более эффективны, когда вы переходите на этап оптимизации.

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...