Я недавно провела рефакторинг приложения среднего размера, и одна из задач состояла в том, чтобы разделить часто используемый код на разные проекты.
Теперь предположим, что обычно используемая структура пространства имен
Core.Interfaces - для основного применения
с интерфейсом IFoo
и для каждой специализированной / внешней / ссылочной сборки я решил сделать расширение, например
Core.Interfaces.Html
с интерфейсом IBar
сборка Core основного приложения находится в проекте с именем Core с пространством имен по умолчанию Core, тогда как для сборки Html я создал проект с именем HtmlCore с пространством имен по умолчанию Core .
Результат (и причина, по которой я выбрал эту конкретную методологию) состоит в том, что после ссылки на сборку Html операторы using обновлять не нужно, и чистый эффект равен
Core.Interfaces.IFoo fooIf;
Core.Interfaces.Html.IBar barIf;
или с использованием оператора Core.Interfaces, приведенное выше преобразуется в
IFoo fooIf;
Html.IBar barIf;
Эта неявная структура пространства имен является прямым результатом зависимостей, и она действительно хорошо нам помогла, поскольку она значительно упрощает обслуживание пространства имен проекта, и единственное, что кому-то нужно иметь, - это ссылка на сборку. Структура аналогична той, что Microsoft уже делает в .net Framework.
Дело в том, что у меня есть вторые мысли и (для будущих проектов) я рассматриваю структуру пространства имен, которая является явной для каждой сборки, например:
Core.DataInterfaces
Html.Core.DataInterfaces
Итак, кто-нибудь работал со структурой явного , с обоими или с чем-то еще, что я не пробовал? Я открыт для предложений и ищу лучшее решение, так как цель состоит в том, чтобы освободить время от обслуживания и путаницы в команде во время разработки.