anton_z писал(а): ↑2019.07.30, 06:41
wolfy-j писал(а): ↑2019.07.29, 17:03
Никто не запрещает работать с DataMapper в виде AR и так-же инкапсулировать соединение или транзакцию, объем кода будет не намного больше. Основной вопрос в том как тестировать такой AR код.
Это уже будет не DataMapper. А вы реально пробовали так делать? Вопрос зачем тогда нужен DataMapper если можно инкапсуляцию подключения пользовать на AR?
AR вместе с базой с фикстурами тестируется без проблем. В Yii2 и codeception для этого есть всё. Заодно протестите, что ограничения БД на типы данных и всякие constraints отрабатывают и не сломают приложение.
P.S. Я не знаю, откуда пошло само восприятие СУБД как какой-то "хранилки". По мне это ошибка, а СУБД - одна из центральных частей приложения, которое работает с данными (например, CRM, магазины, сайты знакомств. СМИ, сайты-агрегаторы и пр.). СУБД уже представляет собой достаточно высокоуровневую абстракцию над голыми данными (SQL это высокоуровневый декларативный язык для работы с данными). Это становится понятно, когда попытаешься реализовать работу с данными на простых файлах в качестве замены СУБД, когда наешься всех этим проблем с конкурентным доступом, вводом/выводом, необходимостью индексирования и прочим. Мое мнение, не надо мощь СУБД ограничивать и закапывать, как это делает DataMapper, а напротив надо дополнять, как делает AR, инкапсулируя подключение.
Как то вы очень негативно настроены против DataMapper. Тогда почему, интересно, его используют на крупных проектах и передовых фреймворках вроде Symfony?) AR, как паттер не плохой. Мне он тоже нравится для простых задач вроде CRUD. Если разработка сложнее чем CRUD — нарушается паттерн единой ответственности .
Как всем известно что одна модель отвечает за сущность, за валидацию, за отображение данных, за сохранение в базу и умудряются ей ещё сохранять Файлы и осуществлять переводы. Поэтому он сложный в больших проектах. Но на старте хорош.
С этим жить можно, но переписывая каждый раз саму модель всякий раз когда одна из ответственностей терпит изменения. Например, нам нужно отобразить данные в другом виде. Нам приходится лезть в модель и добавлять/изменять метод доменной сущности. А если бы у нас было отдельная ViewModel, то данные бы мы изменили только там. К тому же мы бы не имели методы для отображения UI в DomainModel. Если из коробки будет хороший генератор кода, то время не сильно увеличится на старте. Зато в дальнейшем сильно уменьшиться.
Тестировать это можно, особенно если не использовали стандартный генерируемый код. Однако такие тесты выполняются на много дольше. С этими тестами много сложностей. Да и зачем нам тестировать поведение бд при модульном тестировании именно доменного слоя? А ещё базу создавать. И тут сразу же тестируем все. И валидация и сценарии и все что не нужно. В итоге код не то что бы применить на другом фреймворке нельзя, а поддерживать сложно как тесты, так и сам код.
Поэтому, DataMapper, наверное, имеет какие-то недостатки, но это лучше, чем зарыться в своём же коде. Зато он позволяет разделить всё по своим ответственностям на слоистую архитектуру. При этом позволяет работать с малым использованием функционала не создавая свои репозитории.
При таком подходе мы можем разделить слои более детально.
Domain Model != ViewModel
Domain Model != Repository
Domain Model != Validation
И так далее...
Кроме того вам не мешает никто использовать ваш совершенный SQL запрос вместо DataMapper) Но вы сами сказали как было проблемно реализовать работу с файлами. Вот так же вам будет проблемно перевести сущности из СУБД обратно в Файлы. Или вам потребуется сделать «плоскую базу» и тут вы уже тоже сломаете свой проект. Как вы будете тестировать в таком случае?)
Ещё раз повторю, что не пытаюсь вас обидеть)) Ждём YII3!))