Блог

Я постоянно слышу о СУХОМ принципе и о том, как он так важен в ASP.NET MVC, но когда я провожу исследования в Google, я, кажется, не совсем понимаю, как это относится к MVC.

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

Может ли кто-нибудь из вас дать некоторое представление о том, как я мог бы использовать СУХОЙ принцип в своей ASP.NET Приложение MVC?

СУХОЙ просто означает «Не повторяйся». Убедитесь, что при написании кода вы пишете его только один раз. Если вы обнаружите, что пишете аналогичную функциональность во всех своих классах контроллеров, создайте базовый класс контроллера, обладающий этой функциональностью, а затем унаследуйте его, или переместите функциональность в другой класс и вызовите ее оттуда, вместо того, чтобы повторять ее во всех контроллерах.

• используйте атрибуты фильтра для управления аспектами (аутентификация, навигация, панировочные сухари и т. Д.)
• используйте контроллер супертипа слоя (примените к нему общие фильтры уровня контроллера, см. Пример mvccontrib).
• напишите пользовательские результаты действий (например, в mvccontrib — например, мы создали один под названием logoutresult, который просто выполняет FormsAuthentication.Logout()
• используйте соглашение для имен представлений
• самое главное — держите действия контроллера в немом состоянии, ищите возможности повторного использования в сервисах

Не Повторяйся. Это может быть применимо ко многим различным аспектам программирования. Самый базовый уровень этого-предотвращение запаха кода. Я не использовал ASP.NET поэтому я не могу конкретизировать его и MVC.

• В шаблонах C предварительно создается несколько копий одной и той же функции.
• В C void * указатели можно использовать аналогичным образом, но с большой осторожностью.
• Наследование от другой функции позволяет функции позволяет другим функциям использовать ту же базу кода без необходимости копирования кода.
• Нормализация данных в базе данных сводит к минимуму избыточность данных. Также придерживаясь СУХОГО принципа.

Когда вы обдумываете «мысль» в проекте. Спросите себя.

1. Я уже написал этот код?
2. Будет ли этот код полезен в другом месте.
3. Могу ли я сохранить кодирование, построив его на основе предыдущего класса/функции.

СУХОЙ не является специфичным для какой-либо одной технологии. Просто убедитесь, что вы смотрите на свои классы с точки зрения функциональности (даже не с точки зрения кодера копирования/вставки) и видите, где происходит дублирование. Этот процесс, вероятно, не произойдет за один присест, и вы заметите дублирование только после просмотра вашего кода несколько месяцев спустя при добавлении новой функции. Если у вас есть модульные тесты, вы не должны бояться удалять это дублирование.

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

DRY следует применять не только к коду, но и к информации в целом. Вы повторяете что-то в своей системе сборки? Есть ли у вас данные, которые следует перенести в общий файл конфигурации и т.д.

Ну, самый распространенный пример, который я могу привести в отношении DRY и пользовательского интерфейса, — это использование таких вещей, как мастер-страницы и элементы управления пользователями.

Мастер-страницы гарантируют, что вы написали весь статический HTML только один раз.

Элементы управления пользователями обеспечивают возможность повторного использования кода. Например, у вас будет много форм, выполняющих базовые вещи, такие как CRUD. Теперь в идеале мы хотим, чтобы все пользователи видели разные страницы для создания и обновления, хотя поля форм в обоих случаях будут почти одинаковыми. Что мы можем сделать, так это объединить все общие элементы управления и поместить их в элемент управления, который можно повторно использовать на обеих страницах. Это гарантирует, что мы никогда не перепечатываем (или не копируем-вставляем) один и тот же код.

DRY особенно важен в MVC из-за увеличения количества файлов для выполнения одной и той же задачи.

По-видимому, существует неправильное представление о том, что все в модели домена должно быть скопировано в виде специальной модели представления. Вы можете сделать так, чтобы модели доменов были моделями доменов, но модели представлений были чем-то, что ничего не знает о специфике домена и было более общим. Например:

Классы модели домена: Учетная запись, Актив, Заказ на покупку

Модель представления: Список, Таблица, Кортеж, Searchformbackingмодель:Проверенные параметры, Параметры вывода и т.д. Само представление может быть гораздо более специфичным для реализации представления.

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