Вам нужны отдельные тестовые проекты для каждого тестируемого проекта.Если предположить, что это действительно модульные тесты, то, например, VENUS.Repository.Tests будет ссылаться только на VENUS.Repository напрямую.На практике это, вероятно, не совсем удастся, если вы не будете высмеивать все , но разделение проектов даст вам гораздо большую ясность цели.
Я думаю, что отдельный проект для«контракты» (я предполагаю, что интерфейсы) ошибочны.Интерфейсы являются общедоступной точкой входа, которую один уровень использует для ссылки на другие уровни.Как таковые, они принадлежат своим соответствующим слоям.То есть IFooRepository принадлежит VENUS.Repository, а не VENUS.Contracts.(Но см. Обсуждение в комментариях.) Если вы соберете их все в одну сборку, вы уничтожите разделение n-уровня, сказав, что «любой, кто хочет взаимодействовать с любым слоем, просто ссылается на VENUS.Contracts, и вы можете разыграться»."
Наконец, и это немного более ситуативно, но мой инстинкт был бы иметь один файл конфигурации в корне композиции (обычно на уровне пользовательского интерфейса) и вставлять зависимости конфигурации в компонентыкак вы их сочиняете.Так, например, строка соединения не входит в VENUS.Config, на которую ссылается VENUS.Repository (как и все остальные), а вместо этого входит в VENUS.UI.Web s app.config.Затем, когда VENUS.UI.Web составляет свою зависимость от репозитория, он передает эту конфигурацию конструктору репозитория.Например:
string fooConnectionString = ConfigurationManager.ConnectionStrings["Foo"].ConnectionString;
IFooRepository fooRepo = new SqlFooRepository(fooConnectionString);
// Now, as you compose the rest of your dependencies,
// inject fooRepo into anything that requires an IFooRepository.
(Это, конечно, пример «инъекции зависимостей бедняков»; если вы планируете использовать подходящую инфраструктуру внедрения зависимостей, будут более приятные способы создания композиций.)
Таким образом, ваш уровень хранилища не имеет концептуальной зависимости от понятия «конфигурация», но вместо этого просто выражает то, что ему нужно, естественным способом объектно-ориентированного программирования: параметры конструктора.