Ограничить нарушение архитектуры - asp.net MVP

Question

Если бы у нас была определенная иерархия в приложении. Для архитектуры 3-х уровневого уровня, как мы ограничиваем последующие разработчики от нарушения норм?

Например, в случае архитектуры MVP (не asp.net MVC) ведущий должен всегда привязывать модель и просматривать. Это помогает при написании правильных программных модулей. Однако у нас были случаи, когда люди напрямую импортировали рассматриваемую модель и называли функции, нарушающие нормы, и, следовательно, тестовые случаи не могли быть написаны должным образом.

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

Answer 1

Боюсь, что это невозможно. Мы пытались добиться этого с помощью атрибутов, и нам это не удалось. Вы можете обратиться к моему past post on SO.

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

alt text http://www.ndepend.com/Res/NDependBig17.png

Answer 2

Вы хотите решить проблему людей с помощью программного обеспечения? Подготовьтесь к миру боли!

Способ решения проблемы заключается в том, чтобы убедиться, что у вас есть способы работать с людьми, чтобы вы не сталкивались с такими проблемами .... Pair Programming/Review. Индукция людей при первом входе в проект и т. Д.

Сказав это, вы можете написать инструменты, которые анализируют программное обеспечение и ищут общие проблемы. Но люди довольно творческие и могут найти всевозможные причудливые способы делать вещи.

Answer 3

Как только все будет заблокировано в соответствии с вашим удовлетворением, придут новые требования, и вам придется прорваться через его сторону.

Обеспечение такой строгости на уровне программирования с помощью .NET почти невозможно, учитывая, что программист может получить доступ ко всем частным членам через отражение.

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

Answer 4

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

1. Больше код запах выйти глядя на потребителях (Юнит-тесты являются лучшим местом для поиска, если у вас есть).

   • Число параметров в конструкторе - это прямая индикация количества зависимостей. Слишком много зависимостей => Класс делает слишком много.
   • Количества (общественные) методов в классе
   • Установка единичных тестов почти всегда будет отдавать прочь

2. Код со временем ухудшается, если не сфокусированное усилие, чтобы очистить технический долг, и рефакторинг , Это верно независимо от языка.

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