Как на самом деле выглядит принцип СУХОГО в ASP.NET MVC?

Question

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

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

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

Answer 1

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

Answer 2

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

Answer 3

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

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

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

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

Answer 4

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

Answer 5

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

Answer 6

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

Классы доменной модели: Account, Asset, PurchaseOrder

Модель представления: список, таблица, кортеж, SearchFormBackingModel: проверенные параметры, выходные данные и т. Д. Само представление может быть гораздо более специфичным для конкретной реализации представления.

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

Answer 7

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

MasterPages гарантирует, что вы написали все статические HTML только один раз.

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

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

Answer 8

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