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

Question

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

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

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

Answer 1

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

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

альтернативный текст http://www.ndepend.com/Res/NDependBig17.png

Answer 2

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

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

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

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

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

Answer 3

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

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

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

Answer 4

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

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

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