Пусть первый камень бросит тот, кто не потерялся в десятках бизнес-логики проекта!
Иногда бизнес-логика проекта может быть многогранной, а также сложной, что приводит к написанию беспорядочного кода, что затрудняет его чтение!
То, что мы хотели бы сделать простым кодом, превращает его в скучная и обескураживающая вещь как для нас, так и для следующего разработчика, которому, возможно, придется ее прочитать.
В свое время Microsoft MVP, а теперь еще и директор Microsoft, Эдуардо Пирес однажды рассказывал о шаблоне спецификации, который очень помог мне реорганизовать все эти правила и проверки.
Идея этого шаблона состоит в том, чтобы сделать его более атомарным (см. Принципы SOLID), помогая нам повторно использовать код и делая наши проверки более читаемыми и интуитивно понятными.
Приступим к кодированию!
Рассмотрим сущность Person:
Мы должны проверить некоторые поля перед вставкой в нашу базу данных, иначе мы можем столкнуться с некоторыми исключениями базы данных, такими как вставка нуля в поле, не допускающее значения NULL.
Кроме того, мы не можем просто передать его клиентской части для проверки до того, как оно поступит на наш сервер.
Помните, что есть еще способы издеваться над некоторыми сообщениями / формами, поэтому лучше проводить валидацию с обеих сторон.
Давайте запрограммируем наш метод Add, который выполнит некоторые проверки, чтобы вставить наш Person в нашу базу данных:
Обратите внимание, что нам нужно много IF для проверки нашей сущности.
От проверки того, являются ли поля пустыми, до более конкретных проверок, таких как проверка CPF (бразильский документ).
Работает нормально, правда? Да! Но ... если мы попробуем использовать шаблон спецификации с пакетом Eduardo Pires ’, DomainValidation? Можем ли мы сделать это лучше?
Перво-наперво нам нужно загрузить пакет через NuGet:
А теперь нам нужно закодировать наши спецификации. По сути, они будут в точности нашими «если» в предыдущем коде:
После этого мы кодируем нашу проверку и модифицируем нашу службу следующим образом:
У нас есть более чистый код, и мы можем сказать, что их атомарность сейчас на хорошем уровне, что делает наши спецификации повторно используемыми для любой другой проверки !!
Хорошо, мы получили ... Но поехали дальше!
В качестве бонуса я хотел бы провести рефакторинг наших спецификаций. Плохо видеть многих из них только для того, чтобы сделать string.IsNullOrWhiteSpace(), не так ли?
Пришло время упростить задачу с помощью лямбда-выражений:
Теперь у нас есть только 2 (и полностью повторно используемые) спецификации для всей проверки !!
И если мы присмотримся, мы легко сможем прочитать и понять, что мы проверяем.
Обобщения и лямбда-выражения - это здорово!
