Будет ли Dapper для извлечения и NHibernate для CRUD работать для веб-приложения

Я планирую использовать Dapper для поиска и NHibernate для операций CRUD. Итак, было бы неплохо следовать этому подходу. Одна из проблем, с которыми я недавно столкнулся, связана с экранами CRUD.

Предположим, у меня есть форма редактирования заказа. Я получаю объект (порядок) из Dapper, и при его обновлении мне нужно присоединить эти объекты к сеансу NHibernate для выполнения операций CRUD. Это не совсем то, что требуется, я имею в виду object.delete ().

Может ли кто-нибудь дать предложения по этому дизайну и есть ли возможность его улучшить. Это веб-приложение, разработанное с использованием asp.net mvc 3.

Вопросы по ответу:

  1. Означает ли фильтр сеанса по действию то, что мы используем для текущей операции. Если да, то должен ли для операции GET быть [DapperSession] вместо [NHSession]?

    [NHSession] ‹< -------- [DapperSession] ПОЛУЧИТЬ РЕЗУЛЬТАТ ДЕЙСТВИЯ

    • DapperSession.Get.Entity(1000)
    • Обратный вид

  2. Я все еще пытаюсь понять шаблон PRG, который вы опубликовали, я отправлю его, если у меня возникнут сомнения.

  3. Поскольку все это происходит для операции «EDIT», было бы разумно просто получить объект с помощью NHibernate. Это избавляет от всего этого процесса с небольшими накладными расходами.


asp.net-mvc-3 dapper nhibernate
person Sunny    schedule 26.08.2012    source источник

Ответы (1)


arrow_upward
2
arrow_downward

На первый взгляд это кажется логичным выбором: использовать Dapper (или другой микро-ORM) для GET и NHibernate для любых методов действий POST на контроллерах. См. Псевдокод): -

[DapperSession]
GET ACTION RESULT
  - DapperSession.Get.Entity(1000)
  - Return view

и для почтового метода

[NHSession, DapperSession]
POST ACTION RESULT
  If Model.State is valid
    - entity = NHSession.Get.Entity(1000)
    - update entity
    - redirect to ...
  end if

 - DapperSession.Get.Entity(1000)
 - return view

Как видите, это не так элегантно, поскольку вам могут потребоваться различные фильтры действий для результата действия POST. Чтобы упорядочить это, вы можете использовать шаблон Post Redirect Get (PRG), чтобы контроллеры GET использовали Dapper, а контроллеры POST имели доступ только к NHSessions.

Подробнее см. принятый ответ по SO. о том, как настроить этот шаблон ..

Теперь ваши результаты действий GET и POST будут выглядеть так: -

[DapperSession, ImportModelStateFromTempData]
GET ACTION RESULT
  - DapperSession.Get.Entity(1000)
  - Return view

и для почтового метода

[NHSession, ExportModelStateToTempData]
POST ACTION RESULT
  If Model.State is valid
    - entity = NHSession.Get.Entity(1000)
    - update entity
    - redirect to ...
  end if

 - return redirect to GET

Однако, как вы можете видеть, все, что я действительно делаю, это заменяю один атрибут фильтра действия другим. НО (и это большое, но, на мой взгляд), вы получаете преимущества от использования паттерна PRG! Честно говоря, это, вероятно, не дает прямого ответа на наш вопрос, но это хороший метод для подражания.

person Rippo    schedule 26.08.2012
comment
Спасибо за вашу ценную информацию. Вчера я размышлял об этом дизайне, похоже, проблема возникает только при операциях UPDATE и DELETE. Для этих операций нам нужно получить объект из NHibernate и выполнить необходимые операции. Описанный вами подход - это то, что я искал. У меня есть несколько сомнений, которые я добавил в вопрос, не могли бы вы внести свой вклад. - person Sunny; 26.08.2012
comment
Да ой, хорошее место, исправлена ​​проблема со смешанными сессиями. Да, на самом деле все результаты действий POST потенциально могут ИЗМЕНИТЬ данные, в отличие от GET. Шаблон PRG останавливает двойную публикацию, и пользователи видят уродливое сообщение: хотите ли вы повторно опубликовать это сообщение формы при нажатии F5. Но он также довольно хорошо подходит для использования микроорганизма только для чтения. - person Rippo; 26.08.2012
comment
Спасибо, Риппо, шаблон PRG работает хорошо и чисто. У меня есть последний вопрос по дизайну, который, возможно, не входит в тему, хотя и актуален. Я использую элементы NHibernate для экранов списков / других операций чтения, которые извлекают данные через dapper и заполняют их. Но мне было интересно, использовать ли этот код против сущностей NHibernate или создать слой DTO и использовать его. Я работал так, потому что это уменьшает отображение в приложении. Но когда я увидел эту проблему в NHibernate, я почувствовал, что если мы не будем заниматься ею в будущем, приложение будет сломано. Есть предположения? - person Sunny; 26.08.2012