FluentNHibernate Unit of Work / Шаблон хранилища Вопросы Вопросы - PullRequest
0 голосов
/ 03 апреля 2010

Я думаю, что я в тупике. У меня есть приложение, которое я построил с нуля, используя FluentNHibernate (ORM) / SQLite (файл db). Я решил реализовать шаблон «Единица работы и дизайн хранилища». Я нахожусь в точке, где мне нужно подумать об окончательной игре, которая запустится как приложение Windows WPF (с использованием MVVM) и в конечном итоге будет реализовывать веб-сервисы / ASP.Net как пользовательский интерфейс.

Теперь я уже создал доменные объекты (сущности) для ORM. И теперь я не знаю, как мне использовать это вне ORM. Вопросы об этом включают в себя:

  • Должен ли я использовать объекты сущностей ORM непосредственно в качестве моделей в MVVM? Если да, я должен поместить бизнес-логику (например, определенные значения должны быть положительными и быть больше, чем другое свойство) в этих объектах сущности? Это, безусловно, более простой подход, и я склоняюсь прямо сейчас. Однако, будут ли ошибки, которые испортили бы этот план?
  • Если ответ выше - нет, то могу ли я создать новый набор классов для реализации бизнес-логики и использовать их в качестве моделей в MVVM? Как бы я справился с переходом между объектами модели и объектами сущности? Я думаю, что реализация конвертера типов будет хорошо работать здесь.

1 Ответ

3 голосов
/ 03 апреля 2010

Чтобы ответить на первую часть вашего вопроса, да, ваша бизнес-логика и проверка должны идти в ваших сущностях. Смысл NHibernate в том, чтобы позволить вам создавать свои сущности так, чтобы они оставались невежественными. Это означает, что вы должны, когда это возможно, проектировать свои сущности так, как если бы вы не заботились о постоянстве. Это не совсем выполнимо, как вы скоро узнаете (вам нужно будет сделать ваши свойства виртуальными, чтобы поддерживать отложенную загрузку, и если вы хотите использовать NHibernate Validator, вы будете украшать свои свойства атрибутами проверки), по большей части NHibernate делает хорошую работу, чтобы держаться подальше от вашего пути.

Что касается использования ваших сущностей в качестве моделей, вы получите смешанные обзоры по этому вопросу. В идеале вы должны создать отдельные классы модели представления и сопоставить их от сущностей с моделью представления, чтобы ваши представления имели доступ только к минимальному количеству необходимой информации. Это также имеет большое значение для предотвращения N + 1 проблем с доступом . Тем не менее, это часто - огромная боль. Конечно, есть такие инструменты, как AutoMapper , которые облегчат перенос свойств вашей сущности в модель представления.

...