Как использовать SOA с nHibernate? - PullRequest
Новая
       0

Как использовать SOA с nHibernate?

3 голосов
/ 10 июля 2011

Прежде всего, поясню несколько слов: когда я использую слово " пользователь ", вы должны понимать " пользователь приложения " и " пациент *" 1006 * "это" элемент "из слоя модели.

Давайте теперь объясним контекст:

  • Клиентское приложение имеет кнопки « get терпеливый » и « update », текстовое поле « имя пациента » и сетку для отобразить возвращенного пациента после нажатия на кнопку « Получить пациента ».

  • На стороне сервера у меня есть метод WCF GetPatient (имя строки), который ищет исправленного пациента и выполняет некоторую бизнес-логику для PatientEntity , используемого с nHibernate. Этот метод возвращает PatientDto (отображение из PatientEntity ). И у меня есть метод Update (PatientDto пациент) метод для обновления измененного пациента.

  • Пользователь может изменить возвращенное значение PatientDto и нажать кнопку « Update ».

Пока у меня есть две идеи для управления " сеансом " через этот senario:

  • Первая идея: я предоставляю свойство " ID " в моем DTO , поэтому, когда пользователь нажимает кнопку обновления, я выполняю поиск на стороне сервера "* 1055" * пациент"с указанным идентификатором, используя nHibernate's" GetByID ()", я обновляю результат с помощью данных из PatientDto и вызываю nHibernate" Update ()"метод.

  • Вторая идея: я вручную создаю на стороне сервера класс CustomSession (я использую это имя для ясности), который инкапсулирует ISession и предоставляет уникальный идентификатор сеанса, который будет путешествие между клиентом и сервером. Итак, когда клиент отправляет на сервер PatientDto и уникальный идентификатор сеанса, я могу получить CutsomSession и обновить пациента с помощью Update () методов ISession

Мне не нравятся эти идеи. Потому что первое - это много накладных расходов, и оно не использует функции nHibernate. И вторая идея требует, чтобы разработчик сам управлял идентификатором CustomSession между вызовами: он подвержен ошибкам.

Кроме того, я уверен, что nHibernate предоставляет такой механизм, хотя я гуглил и ничего не нашел по этому поводу.

Тогда мои вопросы:

  • Какой механизм (шаблон) я должен использовать? Конечно, механизм должен поддерживать граф объектов, а не одну сущность! "
  • Предоставляет ли nHibenrate такой механизм? *

Заранее спасибо за помощь,

Ответы [ 3 ]

1 голос
/ 11 июля 2011

Я не думаю, что это проблема Hibernate, и, на мой взгляд, это распространенное недоразумение. Hibernate - это OR-Mapper, поэтому он обрабатывает объекты базы данных и обеспечивает базовую поддержку транзакций. Это почти все.
Решением для управления сеансом в средах клиент-сервер является, например, использование, например. Spring.net, который предоставляет решения (поиск OpenSessionInView) для вашей проблемы и довольно хорошо интегрируется с NHibernate.
Упомянутый вами подход без сохранения состояния дает много преимуществ по сравнению с решением на основе сеансов. Например, подумайте о параллелизме. Если ваш comitt не имеет состояния, вы можете просто отреагировать на неудачную операцию Save () на стороне клиента, например, перезагрузив представление.
Кроме того, ваши 2 хороших аргумента в пользу использования Hibernae - это, если все сделано правильно, безопасность против SQL-инъекции.

0 голосов
/ 12 июля 2011

Вот краткое изложение того, что было сказано:

  • Сеанс nHibernate длится время вызова службы.То есть время вызова « GetPatient (имя строки) » не более.
  • Сервер работает с сущностями и возвращает DTO для клиента.
  • Клиентотображает и обновляет DTO.И вызывает службу « Обновление (PatientDto пациенту) »
  • Когда клиент запускает службу « Обновление (PatientDto пациенту) », преобразователь получает сущности пациента благодаряк идентификатору, содержащемуся в DTO, с " GetById (int id) " и обновляет свойства, которые должны быть.
  • И, наконец, сервер вызывает nHibernate « Update () », чтобы сохранить все изменения.
0 голосов
/ 10 июля 2011

Одна из причин, по которой я обычно не беспокоюсь об инструментах / инфраструктурах ORM в программировании клиент-сервер, заключается в том, что вы, как правило, используете свое первое решение.Это помогает сделать серверную часть более не имеющей состояния (и, следовательно, более масштабируемой) за счет некоторых достаточно дешевых вызовов базы данных (выборка с PK обычно очень дешева, и, если вы все же сразу же напишите это, догадайтесь, какая база данных вероятнасделать сначала при записи? Захватить старую запись - поэтому SELECT / UPDATE может быть лишь незначительно медленнее, чем просто UPDATE, потому что он заполняет кэш).

Да, вы делаете вещи вручную, которые хотите нажатьв ORM - такова жизнь.И не беспокойтесь о производительности, пока вы не измерили ее - в данном конкретном случае мне интересно, действительно ли вы можете ее измерить.

...