Мы часто слышим в каждой области, что придерживайтесь основ и будьте проще (KISS). По мере роста программного проекта становится все труднее содержать код в чистоте и порядке. Инженерам приходится писать код в сжатые сроки, что приводит к неправильному выбору, поспешным решениям и сложному проектированию системы.
В этом блоге мы обсудим 7 самых простых вещей, о которых вы всегда должны помнить, чтобы ваша кодовая база оставалась чистой.
Один контроллер — несколько вещей
Запрашивать у одного контроллера несколько вещей — неправильно.
Один контроллер должен делать одну-единственную вещь. Например, если мы создали контроллер категории. Контроллер категорий должен делать только вещи, связанные с категориями. Если вы обнаружите, что пишете код, не связанный с категорией, в контроллере категорий, вам следует подумать о создании нового контроллера, который должен отвечать за эту работу.
Основная обязанность инженера — поддерживать удобство использования API. Если ваши маршруты становятся слишком длинными или сложными, вы можете подумать о создании новых контроллеров.
Всегда помните о принципах SOLID и KISS при разработке каждого модуля.
Обработка исключений
Обработка исключений является неотъемлемой частью любого приложения. Вам следует избегать обработки исключений в каждом методе, особенно в контроллерах.
.Net предоставляет нам различные способы обработки исключений. Один из способов — использовать промежуточное ПО, а другой — использовать глобальные фильтры исключений.
Вместо обработки исключения на уровне действия:
Сделайте следующее:
Используйте ExceptionFilterAttribute и напишите собственную логику для глобальной обработки исключений в приложении. Это делает код компактнее, как показано ниже:
Зарегистрируйте фильтр исключений в классе запуска:
Тесная связь и зависимость
Основным принципом разработки программного обеспечения является поддержание низкой связанности и высокой связанности между программными модулями. Иногда так легко упустить из виду этот основной принцип проектирования систем.
.Net Core предоставляет готовое решение, известное как внедрение зависимостей (DI). Очень легко зарегистрировать зависимости.
После регистрации службы становятся доступными на протяжении всего жизненного цикла приложения. Существуют различные способы регистрации для получения услуг. Вы можете прочитать больше об этом здесь".
Важно отметить, что существует 3 разных срока действия для регистрации сервисов. (переходный, ограниченный, одноэлементный)
Контроллер поддерживает внедрение зависимостей, и вы можете внедрять службы в конструктор. После введения они доступны по всему контроллеру.
DAL (уровень доступа к данным)
Мы никогда не должны использовать контроллер для прямого доступа к данным. Для проектов среднего и большого размера мы всегда должны использовать шаблон репозитория для доступа к уровню данных. Это делает код доступным для тестирования и сопровождения. Мы можем легко протестировать наши контроллеры и репозитории, если они оба делают только одну вещь. На следующем изображении мы должны вызывать службу категорий, которая затем вызывает репозиторий категорий, чтобы получить запись категории с заданным идентификатором.
Сопоставление классов вручную
Когда мы разрабатываем приложения, мы часто пишем повторяющийся код. Это увеличивает время разработки. Особенно, когда у нас есть DTO (объекты передачи данных), которые сопоставляются с моделями на бэкэнде. Мы должны использовать AutoMapper.
Вместо ручного сопоставления DTO с моделями, как показано ниже:
Мы можем использовать AutoMapper и одной строкой сопоставить весь DTO с моделью.
Бизнес-логика
Мы никогда не должны выполнять бизнес-логику на уровне контроллера. Сделав это, мы повторим код и попросим контроллер сделать более одной вещи, которая нарушает принцип SOLID.
Мы должны создать сервисный слой, где мы должны выполнять бизнес-логику. Позже, если нам понадобится использовать ту же бизнес-логику в каком-то другом модуле. Мы можем просто внедрить тот же сервис и использовать бизнес-логику. Это делает код компактнее.
На следующем изображении мы обновляем доступные SKU для данного продукта. После этого мы сохраняем информацию о продукте в базе данных, а затем загружаем файлы продукта на сервер.
Ручная авторизация
.Net предоставляет нам простой способ аутентификации и авторизации пользователей. Мы должны использовать ключевое слово Авторизовать, чтобы проверить, есть ли у пользователя доступ для выполнения определенной функции. Мы можем сделать это, украсив контроллер или действие ключевым словом авторизации с заданным именем роли. В следующем сценарии я реализовал политику «RequireModeratorRole», которая принимает роли «Администратор, модератор» для доступа к контроллеру продукта.
Заключение
Это 7 самых важных вещей, о которых вы должны помнить в следующий раз, когда будете проектировать систему или писать код. Любой инженер может спроектировать систему, но только хороший инженер проектирует гибкую, ремонтопригодную, тестируемую и масштабируемую систему.
