Во-первых, легко пойти за борт, глядя на зависимости и связи. Убедитесь, что вы не слишком усложняете это.
С этим отказом от ответственности, вот что я предлагаю.
На самом деле есть три разных взгляда на управление зависимостями / связями:
1) физическая структура (то есть зависимости сборки)
2) логическая структура (то есть зависимости пространства имен)
3) структура реализации (то есть зависимости класса)
Для больших приложений вам нужно будет как минимум изучить все 3, но обычно вы можете расставить приоритеты.
Для приложений, развернутых на клиенте, номер 1 может быть очень важен (то есть для таких вещей, как плагины). Для приложений, развернутых внутри предприятия (например, asp.net), элемент № 1 обычно оказывается не столь важным (исключая рамки, многократно используемые в нескольких приложениях). Обычно вы можете развернуть все приложение достаточно просто, чтобы не перегружать сложную структуру для # 1.
Элемент № 2, как правило, больше связан с ремонтопригодностью. Знайте границы своего слоя и их связь с пространствами имен (т.е. вы делаете 1 слой на пространство имен или вы упакованы по-разному на логическом уровне). Иногда инструменты могут помочь вам усилить границы вашего слоя, посмотрев на структуру логической зависимости.
Пункт № 3 действительно о том, чтобы сделать хороший дизайн класса. Каждый хороший разработчик должен приложить немало усилий, чтобы убедиться, что он берет на себя только правильные зависимости в своих классах. Это легче сказать, чем сделать, и, как правило, это навык, который нужно приобретать со временем.
Чтобы немного приблизиться к сути вашего вопроса, пункт № 1 действительно о том, как проекты размечены в решении VS. Так что это не предмет для измерения. Это больше того, что вы настраиваете в начале и позволяете запустить. Пункт №2 - это то, что вы можете использовать инструмент для проверки во время сборок, чтобы увидеть, если разработчики нарушили какие-либо правила. Это скорее проверка, чем мера. Пункт № 3 действительно тот, который вы хотели бы хорошо посмотреть на измерения. Поиск классов в вашей кодовой базе, которые имеют большое количество связей, станет болевыми точками в будущем, обеспечьте качество этих парней. Кроме того, измерения на этом уровне позволяют получить представление о качестве (в целом) кодовой базы по мере ее развития. Кроме того, он может дать вам красный флажок, если кто-то проверяет какой-то действительно неуклюжий код в вашей кодовой базе.
Итак, если вы хотите расставить приоритеты, взгляните на № 1 и № 2. Знайте, как они должны выглядеть. Но для большинства приложений пункт № 3 должен занимать больше всего времени.
Этот ответ, конечно, исключает огромные фреймворки (такие как .NET BCL). Этим детям нужно очень внимательно относиться к # 1. : -)
В противном случае вы столкнетесь с такими проблемами:
«Текущие версии .NET Framework включают множество библиотек на основе графического интерфейса, которые не будут работать должным образом в Server Core»
http://www.winsupersite.com/showcase/win2008_ntk.asp
Там, где вы не можете запустить .NET при установке Windows Server 2008 без графического интерфейса, поскольку платформа принимает зависимости от библиотек графического интерфейса ...
И последнее. Убедитесь, что вы знакомы с принципами хорошего управления зависимостями и связями. Вы можете найти хороший список здесь:
http://butunclebob.com/ArticleS.UncleBob.PrinciplesOfOod