Использование nHibernate в качестве ORM для нескольких источников? - PullRequest
0 голосов
/ 19 октября 2011

Я успешно использую Fluent nHibernate во многих веб-приложениях <-> db и мне это очень нравится. Использовать только базу данных в качестве источника довольно просто, есть только проблемы в определении модели вашего домена, создании соглашений, отображений и т. Д.

Теперь, однако, я столкнулся с другим подходом и хотел бы получить некоторую информацию, прежде чем принять решение с использованием nHibernate.

Теперь в слое постоянства есть три или более разных источника данных, и иногда вы будете писать / читать один из них, а иногда и все. Я полагаю, что для решения этой проблемы хорошо подходит единица работы.

  • 0..1 База данных
  • 0 .. * файлы в файловой системе
  • 0 .. * аппаратное обеспечение

И поэтому будут существа, поступающие из разных источников, некоторые из которых созданы вручную, другие сопоставлены с БД.

Есть ли хорошие идеи о том, как подходить к этому сценарию, и все-таки имеет ли смысл использовать репозитории с nHibernate, работающие с разными источниками?

Мои мысли:

Разделите часть db / nhib с другими источниками и создайте на ней хранилище или фасад (чтобы открыть BL). Это знает, как работать с различными источниками. Вероятно, необходимо создать новое определение сущностей, поскольку они могут содержать данные из разных источников и представляться как «один». Таким образом, я все еще мог бы использовать nHib для доступа к БД, написать другой код DAL для других частей и скрыть реализацию от BL.

Имеет ли это смысл, или это можно решить лучше, используя nHib?

1 Ответ

0 голосов
/ 19 октября 2011

Разные сущности имеют разные источники

было бы достаточно фасада, подобного Repositories, UnitOfWorkClass или пользовательскому SessionWrapper, реализующему ISession. самая сложная часть - это транзакции с такими источниками, как файлы

Когда объекты имеют некоторые свойства из разных источников

я бы использовал IUserTypes как здесь

Объекты смешаны из разных источников

я бы представил классы Wrapper с внутренними объектами, содержащими состояние для каждого источника данных, возможно, с соответствующим объектом unitofwork

...