.NET проект / организация пространства имен вопрос - PullRequest
Новая
       33

.NET проект / организация пространства имен вопрос

3 голосов
/ 13 мая 2011

У нас есть структура, которая определяет множество интерфейсов и некоторые базовые реализации по умолчанию.Давайте назовем это CompanyFramework.У меня есть несколько расширений ASP.NET MVC, в настоящее время хранящихся в отдельном проекте CompanyFramework.Web.Mvc.Причина этого в том, что приложения, которые используют базовую платформу, но не имеют ничего общего с MVC, не должны ссылаться на библиотеки ASP.NET MVC.Мне не очень нравится эта настройка, так как дополнительная сборка содержит только 3-4 файла классов, но это был самый чистый способ избежать введения ненужных зависимостей в основную сборку фреймворка.

Теперь у нас есть структура StructureMap-специфичные расширения, которые мы используем для ASP.NET MVC, а именно: фабрики пользовательских контроллеров и вещи типа подшивки моделей.Где бы вы положили что-то подобное?Я мог бы просто добавить его в проект CompanyFramework.Web.Mvc, но затем в любой проект ASP.NET MVC, который использует ссылку на сборку StructureMap, даже если она не используется.Я также мог бы создать отдельный проект CompanyFramework.StructureMap, но тогда, если я когда-нибудь разработаю какие-либо расширения для StructureMap, которые не зависят от ASP.NET MVC, я все равно буду сослаться на ссылки на сборки MVC для классов, которые их используют.

Должен ли я создать отдельный проект CompanyFramework.Web.Mvc.StructureMap?Этот подход кажется наиболее чистым в целом, но я чувствую, что начинаю вводить несколько легких спутниковых сборок, которые загромождают общую структуру проекта.

Ответы [ 3 ]

2 голосов
/ 13 мая 2011

Что хуже, плохие зависимости или несколько дополнительных проектов?Слегка загроможденная IDE - это небольшая цена за четко определенную структуру.

1 голос
/ 13 мая 2011

По любому вопросу, подобному этому, я считаю полезным рассмотреть долгосрочные последствия решения в отношении будущих модификаций. В конце концов, некоторые из этих библиотек будут устаревшими и замененными, в то время как другие будут жить. Например, появится некоторая технология, которая заменит MVC.

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

Кроме того, постоянно расширяющаяся библиотека Big Ball of Mud - это не то, что вы захотите использовать в каждом проекте в будущем по многим другим причинам. «Куча легких сборок» звучит для меня как отличная дизайнерская цель.

0 голосов
/ 13 мая 2011

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

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

...