@Multu

Одно действие с множеством модификаций. Как организовать архитектуру?

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

Суть его в следующем. Пользователь (на уровне его профиля закреплен вид договора) заполняет несколько простых форм (для заключения договора) следующего вида:
ФИО, телефон, email, адрес, и т.д. И эти данные сохраняются для заявления на оказание услуг.

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

Пока что решаю проблему так, что создаю для каждого случая новый метод, новое предоставление (по сути на 95% копипастой занимаюсь), например createBookerRu, createAsat, createBookerUa. Методы везде идентичные, кроме проверок на валидацию формы, а представления я привожу к нужному виду. Кол-во видов договоров начало сильно расти, уже около 70 вариантов, и далее еще будет расти. На каждый вид заводить свой метод кажется утопией.

Подскажите, если уже приходилось решать подобную проблему, в какую сторону вообще смотреть?
Свое видение: иметь один метод create, который умеет обработать любой вид договора, но не понятно, каким образом сделать динамичными представления, как провести валидацию формы, как быть если одно и тоже поле (телефон) может иметь разные требования валидации (Беларусь, Россия, Украина)?
  • Вопрос задан
  • 190 просмотров
Пригласить эксперта
Ответы на вопрос 2
27cm
@27cm
TODO: Написать статус
Я бы попробовал использовать паттерн Factory.
Фабрика будет создавать форму для конкретного типа документа, в ней не должно быть дублирования кода.
Список полей и правила их валидации для каждого типа договоров хранить в конфигурационных файлах concrete-document-type.php:
<?php
return [
    'elements' => [
        'name',
        'surname',
        'phone' => [
            'validators' => ['by']
        ],
        ...
    ],
    ...
];

Структуру привёл условную. Фабрика должна уметь по требуемому типу договора получить нужный конфигурационный файл и по нему построить нужную форму договора.

У вас получится 70 конфигурационных файлов. Дальше можно думать, как их максимально упростить. Например, у вас есть PhoneElement формы, использующий PhoneValidator, вы создаёте его наследника PhoneByElement с валидатором беларусского номера телефона. И конфигурационный файл превращается в:
<?php
return [
    'elements' => [
        'name',
        'surname',
        'phone_by',
        ...
    ],
    ...
];


Или добавляете понятие локали в конфигурационный файл:
<?php
return [
    'country' => 'by',
    'elements' => [
        'name',
        'surname',
        'phone',
        ...
    ],
    ...
];
Ответ написан
@oxidmod
можно еще посмотреть в сторону билдера для формы
Ответ написан
Ваш ответ на вопрос

Войдите, чтобы написать ответ

Войти через центр авторизации
Похожие вопросы
HORIBA Москва
от 140 000 руб.
Хабр Москва
от 150 000 руб.
GXB Development Йошкар-Ола
от 80 000 до 160 000 руб.
14 дек. 2019, в 11:44
500 руб./за проект
14 дек. 2019, в 11:23
2000 руб./за проект