post = PostService.Get(id);
comments = post.Comments;
Обход этой модели возможен и желателен. Однако вы абсолютно правы в том, что это идеал реализации, который имеет высокую производительность, особенно при работе с коллекциями (и у вас не останется волос, когда дело доходит до иерархических структур данных).
Вы хотите настроить сопоставления NH для пакетной отложенной загрузки. (fetch = subselect batch-size = #), в противном случае активная загрузка приведет к извлечению слишком большого объема данных, а отложенная загрузка приведет к проблеме выбора N + 1 (1 запрос для получения сообщений, + N запросов для получения комментариев, где N количество постов - ваша петля).
Если ваше требование действительно отображать 2 комментария для каждого сообщения, то подойдет пакет 2, но, как вы, без сомнения, догадались, как только ваше приложение попытается получить доступ к 3-му комментарию, NH выполнит еще один выбор. чтобы заполнить коллекцию комментариев еще 2, так что вы можете захотеть большего размера партии с самого начала. Планируйте этап настройки перфом, когда вы знаете свои варианты использования. Это может быть очень сложно, если вы разрабатываете API доступа к данным общего назначения. (Кроме того, вы захотите добавить order-by = "SOME_COLUMN_NAME" в сопоставление вашей коллекции комментариев, чтобы контролировать, как получить "первые" комментарии). Легко недооценить важность настроек сопоставления NH; ORM решает множество проблем разработчиков, но добавляет целый мир новых.
Эрик Эванс, «Управляемый доменом», определяет схему и сервисы хранилища. Они не всегда уместны. Я перестал использовать их для всех, кроме очень сложных проектов, и редко на сборках MVC. Преимущества шаблона и служб репозитория - это разделение, изоляция, тестируемость и гибкость ваших архитектурных компонентов. В реальных условиях - рассмотрите ваши пространства имен «использования». Если вы предпочитаете не использовать nhibernate в своих контроллерах, то спрячьте его в хранилище и просто ссылайтесь на сборку репо.
Это связано с тестируемостью - вы можете тестировать репозиторий отдельно от контроллеров. Если вы сейчас обижены наличием ссылок репо в своих контроллерах, тогда используйте сервисный уровень. Это все о слабой связи.
Преимущества сервисного уровня включают в себя полное скрытие механики доступа к данным, удаленное раскрытие методов сервиса по сравнению с другими вариантами транспорта (например, веб-сервисами) и завуалирование общих методов репозитория с именами, дружественными API. Например, post = MyAwesomeAPI.PostService.Get (id); может быть просто оболочкой для универсального - получить любой тип по id - Repository.Get (id); Эта оболочка API чрезвычайно полезна при разработке набора сервисов для сторонних разработчиков или просто для других разработчиков в вашей команде. Если ваши сигнатуры методов остаются прежними, вы можете изменить базовую реализацию в любое время - например, ваш переход с NH на обычный SQL не нарушит существующие приложения, использующие этот API.
Для максимальной гибкости вы бы даже не связывали свою сборку сервисов с вашей сборкой реализации репо вообще. Скорее вы бы использовали инструмент внедрения зависимостей, такой как Structure Map, чтобы связать все во время выполнения. Это позволяет вам переключать реализации репозитория одной лишь конфигурацией без перекомпиляции / компоновки. Вы могли бы даже иметь несколько методов доступа к данным. Потребитель API не будет знать и не должен заботиться.
Если вам не нужно ничего из этого, поместите «using nhibernate» в свои контроллеры и все готово. Риск состоит в том, что вы жестко привязали свое приложение MVC к NH, и каждый должен знать все, чтобы внести наименьшее изменение в ваше приложение. Это решение, скорее всего, будет принято из-за ограничений вашего проекта (время / деньги / люди / календарь). Если вам все это нужно, проверьте архитектуру Sharp или соберите свой собственный стек. MVC намного больше VC, чем М.