Где должны находиться хранилища данных конфигурации сайта?

Question

У нас есть несколько сущностей NHibernate, которые сопоставляются с данными, предназначенными специально для настройки мультитенантного веб-приложения.Эти объекты существуют в проекте Domain вместе с остальными объектами NHibernate.

Дело в том, что все остальные сущности связаны с бизнесом , где эти сущности связаны с конфигурацией .Имеет ли смысл иметь их в Интернете?

Причина, по которой я спрашиваю, заключается в том, что я столкнулся с проблемой, описанной в этом вопросе: Как предоставить данные RequestContext конструктору доменаобъект? , где мне нужны данные из контекста запроса, предоставленные в конструкторе объекта домена.Проблема в том, что я не хочу ссылаться на веб-проект из проекта Domain.Если бы я получал данные конфигурации непосредственно из веб-проекта, это не было бы проблемой.

edit : "Имеет ли смысл иметь их в домене?"исправлено на ".. в сети?"

Answer 1

Лично для своих проектов я быстро разбиваю свои репозитории, модели и т. Д. На отдельные сборки (не только на основе шины / конфигурации / и т. Д.).

Так что в ситуации, когда хранилищу нужен доступ к информации из RequestContext, у меня будет отдельный хранилище, настроенный для этих данных конфигурации, и в отдельной сборке из моих бизнес-хранилищ / объектов.

Даже в пределах моих доменных объектов (и в нашем проекте по здравоохранению у нас есть десятки) мы быстро выясняем основные швы, где мы можем разбить вещи - то есть компонент, который имеет дело с сформированными данными, не должен нести вес всего нашего домена, поэтому мы явно настраиваем объекты отображения, которые хотим использовать в нашем конфигурационном файле, и сохраняем наши доменные объекты в разбивке по логическим функциям.

Короче говоря, я не стал бы моргать, рассматривая возможность разделения ваших конфигурационных сущностей на отдельный проект / сборку (как правило, наши сборки включают общий интерфейс хранилища, наш конкретный репозиторий, сопоставления NHibernate и соответствующую модель).