Расширяемая модель предметной области с помощью NHibernate
В настоящее время я разрабатываю решение, в котором модель домена и хранилище могут быть расширены за счет плагинов приложений. Теперь я столкнулся с несколькими проблемами, которые я перечисляю ниже.
Моя первая проблема - сделать доменную модель расширяемой. Я думал об использовании здесь наследования, но, честно говоря, я понятия не имею, как я могу использовать несколько сборок плагинов, расширяющих один и тот же объект домена. Я склоняюсь к тому, чтобы сделать каждый предметный объект частичным и позволить плагинам расширять его таким образом. Если у меня есть несколько плагинов, расширяющих один и тот же объект домена, мне не придется беспокоиться о загрузке различных сборок расширенного домена для каждого плагина. У меня все еще был бы только один объединенный объект домена во время выполнения. Есть идеи по этому поводу?
Другая проблема заключается в расширении файла сопоставления NHibernate. Я мог бы создать файл сопоставления для каждой сборки для объекта домена, который он расширяет, и чтобы мой менеджер NHibernate загружал его вместо того, который был предоставлен в основном домене. Еще раз, проблема в том, что если у меня есть несколько плагинов, расширяющих один и тот же объект домена. Я мог бы иметь один файл переопределения одного плагина для другого. У меня есть не очень хорошее решение последней проблемы, но я думал о том, чтобы включить контрольную сумму в сборку плагина в качестве подписи для исходного файла отображения, который он использовал, прежде чем расширять его. Я могу проверить эту контрольную сумму во время загрузки и загрузить карту плагинов, только если контрольные суммы совпадают. Довольно уродливо, но по крайней мере я не буду переопределять карты, которые отличаются от базовой карты, используемой для расширения в сборке плагина.
В любом случае, я хотел бы услышать, что вы, ребята, думаете по этому поводу. Спасибо!
2 ответа
Хорошей новостью является то, что то, о чем вы просите, возможно и не так сложно в управлении.
Об управлении подключаемыми модулями вы можете взглянуть на Microsoft Prism ( http://msdn.microsoft.com/fr-fr/magazine/cc785479.aspx), которая представляет собой несколько приятных особенностей разработки модульных приложений.
О 1. Вы можете отобразить подклассы в отдельных отображениях, в отдельных сборках, ищите документацию NH. Отдельный файл сопоставления для подкласса выглядит следующим образом:
<?xml version="1.0" encoding="utf-8" ?>
<hibernate-mapping xmlns="urn:nhibernate-mapping-2.2">
<subclass name="YourClassFullName, YourPluginAssemblyName"
extends="YourParentClassFullName, TheAssemblyWhereYourBaseClassIsDefined"
discriminator-value="whateveryouwant">
... add your subclass mapping here ...
</subclass>
</hibernate-mapping>
Около 2. Вы можете сохранить основной домен сопоставления. Более простым способом было бы создать службу (скажем, IMappingLoader), которую ваши плагины могут использовать для регистрации ваших дополнительных сопоставлений (без переопределения сопоставления базового класса). Ваша реализация этого сервиса добавит ваше отображение в класс NH Configuration. Например, в Microsoft Prism все ваши плагины должны реализовывать интерфейс IModule, функция которого Initialize() вызывается при загрузке. Эта функция является идеальным местом для вызова вашего сервиса IMappingLoader.
Надеюсь, это помогло.
Чтобы получить расширяемую модель предметной области, я буду использовать множество фабрик. Фабрики могут быть выгружены / извлечены через внедрение зависимостей, а доменные объекты должны быть закодированы для интерфейсов.
Сопоставление может быть сделано, например, через Fluent NHibernate, и они могут быть в той сборке плагина.
Наконец, я бы добавил загружаемую конфигурацию к той сборке плагина, которая настраивает DI-контейнер и загружает новые сопоставления. Для основной сборки может быть сканер для конфигурации плагинов. Может быть, MEF мог бы помочь здесь, или вы могли бы сделать свой собственный, который не должен быть сложным.