Должен ли я быть более заинтересован в связи между пакетами или между единицами распределения? - PullRequest
2 голосов
/ 24 сентября 2008

Я искал показатели для связи , а также смотрю на DSM .

Один из инструментов, который я использовал, рассматривает связь между «модулями» с модулем, являющимся единицей распределения (в данном случае сборкой .net).

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

Должен ли я больше интересоваться связью между пакетами / пространствами имен (убедитесь, что абстракции зависят только от абстракций, конкретные типы зависят от абстракций и они не являются циклами в зависимостях, так что рефакторинг и расширение просты) или мне следует заняться могу ли я развернуть новые версии без необходимости обновления неизменных единиц распространения?

Что еще кто-то измеряет?

Что бы это ни стоило, мое внутреннее чувство заключается в том, что, если я сосредоточусь на соединении пакет / пространство имен, тогда единица распределительной связи придет бесплатно или, по крайней мере, будет проще.

Ответы [ 2 ]

3 голосов
/ 24 сентября 2008

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

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

На самом деле есть три разных взгляда на управление зависимостями / связями: 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

0 голосов
/ 24 сентября 2008

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

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

...