Должен ли я быть более озабоченным связью между пакетами или между единицами распространения?

Циклы связывания и зависимости между единицами распространения более «фатальны», потому что они могут действительно затруднить развертывание вашей программы - а иногда это также может затруднить даже компиляцию вашей программы.

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

Во-первых, легко переборщить, глядя на зависимости и взаимосвязь. Убедитесь, что вы не слишком усложняете его.

С учетом этого отказа от ответственности я предлагаю вот что.

На самом деле существует 3 разных представления для управления зависимостями / связями: 1) физическая структура (т.е. зависимости сборки) 2) логическая структура (т.е. зависимости пространства имен) 3) структура реализации (т.е. зависимости классов)

Для больших приложений вам нужно будет как минимум изучить все 3, но обычно вы можете расставить приоритеты.

Для приложений, развернутых клиентом, номер 1 может быть очень важным (например, для таких вещей, как плагины). Для приложений, развернутых внутри предприятия (например, asp.net), пункт 1 обычно оказывается не столь важным (за исключением фреймворков, повторно используемых в нескольких приложениях). Обычно вы можете развернуть все приложение достаточно просто, чтобы не брать на себя накладные расходы, связанные со сложной структурой для №1.

Пункт № 2, как правило, больше связан с ремонтопригодностью. Знайте границы своих слоев и их отношение к пространствам имен (т.е. делаете ли вы по одному слою на пространство имен или упаковываете ли вы по-другому на логическом уровне). Иногда инструменты могут помочь вам установить границы вашего слоя, глядя на структуру логических зависимостей.

Пункт № 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