Я бы хотел обсудить энтерпрайз, ведь не каждый энтрерпрайз такой нагроможденный и «кровавый». Есть большие проекты, с хорошим доходом, но при этом не так сильно заморачиваются над культурой разработки, так как бизнес важнее и ему важна скорость поставки фич.
Писать код с Active Record быстро и легко, в том случае, когда свойства объекта прямо соотносятся с колонками в базе данных.
Сохранение происходит в одном месте, что позволяет легко изучить, как это работает.
Недостатки Active Record
Модели Active Record нарушаю принципы SOLID. В частности, принцип единой ответственности (SRP — «S» в принципах SOLID). Согласно принципу, доменный объект должен иметь только одну зону ответственности, то есть только свою бизнес-логику. Вызывая его для сохранения данных, вы добавляете ему дополнительную зону ответственности, увеличивая сложность объекта, что усложняет его поддержку и тестирование.
Реализации сохранения данных тесно связана с бизнес-логикой, а это означает, что если вы позже захотите использовать другую абстракцию для сохранения данных (например для хранения данных в XML-файле, а не в базе данных), то вам придется делать рефакторинг кода.
Преимущества использовать Repository (паттерн Data Mapper)
Каждый объект имеет свою зону ответственности, тем самым следую принципам SOLID и сохраняя каждый объект простым и по существу.
Бизнес-логика и сохранение данных связаны слабо, и если вы хотите сохранять данные в XML-файл или какой-нибудь другой формат, вы можете просто написать новый Mapper, не притрагиваясь к доменному объекту.
Если вы пишете сложную бизнес-логику и хотите внедрить DDD, то использование паттерна Data Mapper лучшее, что можно придумать для отображения доменных моделей в таблицы бд (поля и таблицы могут не совпадать со всеми доменными моделями).
Недостатки использовать Repository
Вам придется гораздо больше думать, перед тем как написать код.
В итоге у вас больше объектов в управлении, что немного усложняет код и его отладку.
Как всегда, вопрос в расширяемости и гибкости кода, чтобы было проще поддерживать и дорабатывать. Стало понятнее?
как посмотреть историю изменений конкретного объекта структуры БД. По каждой таблице хочется посмотреть историю изменений в связи с решением конкретных задач.
Вот тут и тут рассказывалось об очень удобной тулзе RedGate SQL Compare. Использовали на проекте одном, вполне годная для версионирования изменений в базе данных, но конфликты она решать не умеет (например при добавлении not null поля в существующую таблицу с данными).
Также в Phalcon Framework видел хорошее решение подобной проблемы, но там тоже не нативный SQL, а DSL описание бд (тут).
Смысл разворачивать такую махину и не пользоваться практически ни чем из его инструментария.
А кто вам сказал, что это махина? Он довольно шустрый и нагрузку намного лучше держит, чем тот же yii2, который вовсе скоро загнется. Можете у Макарова спросить, который ушел писать на симфони в skyeng
Я бы отключил эту функцию. Мне не нравится текст в редакторе, который на самом деле отсутствует. Не нравится поведение курсора при клике на такие «фантомы».
Достаточно подсказки типа при Ctrl+Hover.
Каждый создатель велосипеда хвалит свой велосипед, но, когда доходит дело до расширения, внезапно обнаруживается, что документации по велосипеду нет, а его автор уволился. И тогда новый специалист принимает решение выкинуть и написать все на известной технологии, по которой есть и документация и на рынке специалистов потом найти легко.
Пишите статью, было бы интересно увидеть ваше решение.
По SOLID можно писать без тестов, но вот тесты нельзя писать по SOLID.
Для того, чтобы тесты работали не обязательно следовать каждому принципу, до большинства вещей доходят при расширении приложения.
Стоит отметить, что SOLID принципы делают разработку более долгой и сложной. Требуется создавать множество интерфейсов и абстрактных классов, что может показаться избыточным и ненужным.
Но при доработке или расширении вашего приложения вы поймете для чего все это было нужно.
Вывод: SOLID принципы хороши в больших и продолжительных проектах, на коротких проектах это долго и дорого.
Я ведь правильно понял, что если в проекте только unit тесты, то данный подход не подойдет?
Если на проекте используется Passpot от Laravel, то соответственно тесты на авторизацию редко пишут, так как там уже готовый пакет. И в документацию эти методы не войдут, верно?
Подход, где один скрипт php отправляет другому php скрипту команду для обновления состояния будет действовать только в рамках одного сервера/виртуалки/контейнера. Но как быть, если два воркера должны общаться друг с другом, но они изолированы друг от друга, например, в разных docker?
Наличие в первоначальной версии фронт контроллера очень сильно упрощает переписывание кода на современные технологии. А вот если бы его не было, то было бы очень больно. Все же у вас не самый хардкорный legacy был.
А что было с проектом, пока вы его переписывали? Бизнес же не может стоять. А если делать постепенно, то есть шанс превратить проект в некоторый франкенштейн, который также сложно поддерживать.
Идея интересная, но так как у подобных решений нет нормальной документации, будет крайне неудобно поддерживать проект на этом велосипеде (и пусть он использует много фишек типа PSR, DI и прочего).
Вопрос работы с бд тоже довольно холиварная тема, поэтому ее и не описывал автор. Сложно будет доказать когда оправдан ActiveRecord, а когда DataMapper. И там тоже все на магии, если самому реализовывать.
Данная статья удобна для стажеров. Буду давать ее для изучение перед изучение полноценных фреймворков.
Полезная статья для понимания общих и базовых принципов во фреймворках, спасибо. Зачастую не всегда в документации к фреймворку объясняется почему именно так сделано, а просто говорится «делай так и так». Большинство начинающих программистов не понимая этих подходов, принципов и их назначение, начинают писать на фреймворке так, что лучше бы не писал вообще код.
Раньше у symfony было что-то подобное в документации, объясняли все по полкам что и зачем. Как это сделать самому и как это сделано в symfony.
А вот в документации по yii вообще все грустно… Не рекомендовал бы для новичков, хотя и простой инструмент.
Вы правда так думаете? Директивный подход этого фреймворка наоборот позволяет не писать кучу кода, а использовать директивы. Интуитивно понятно же получается! Или для вас ванильный js более интуитивный из кучи строк лапши-кода?
А для простых вещей используют ванильный javascript, зачем тащить в проект библиотеку для вызова одной функции?
JQuery и Vue.js совершенно разные две оперы. Ведь jQuery используют для работы с DOM деревом напрямую, когда Vue.js использует состояния и модели. Взгляните хотя бы на их двусторонний биндинг из angularjs.
И я не понимаю откуда взялся этот vue,js и почему его все так пропихивают, когда есть такие шикарные инструменты, как angularJS и react + redux.
Почему это должно рушиться? В той же Symfony нормально живут описание зависимостей в модели, а получение данных через репозитории.
Напишите хотя бы один проект на Symfony и тогда в каждом проекте будет не хватать Doctrine с репозиториями.
Недостатки Active Record
Преимущества использовать Repository (паттерн Data Mapper)
Недостатки использовать Repository
Как всегда, вопрос в расширяемости и гибкости кода, чтобы было проще поддерживать и дорабатывать. Стало понятнее?
Вот тут и тут рассказывалось об очень удобной тулзе RedGate SQL Compare. Использовали на проекте одном, вполне годная для версионирования изменений в базе данных, но конфликты она решать не умеет (например при добавлении not null поля в существующую таблицу с данными).
Также в Phalcon Framework видел хорошее решение подобной проблемы, но там тоже не нативный SQL, а DSL описание бд (тут).
А кто вам сказал, что это махина? Он довольно шустрый и нагрузку намного лучше держит, чем тот же yii2, который вовсе скоро загнется. Можете у Макарова спросить, который ушел писать на симфони в skyeng
Я бы отключил эту функцию. Мне не нравится текст в редакторе, который на самом деле отсутствует. Не нравится поведение курсора при клике на такие «фантомы».
Достаточно подсказки типа при Ctrl+Hover.
Пишите статью, было бы интересно увидеть ваше решение.
Для того, чтобы тесты работали не обязательно следовать каждому принципу, до большинства вещей доходят при расширении приложения.
Но при доработке или расширении вашего приложения вы поймете для чего все это было нужно.
Вывод: SOLID принципы хороши в больших и продолжительных проектах, на коротких проектах это долго и дорого.
Если на проекте используется Passpot от Laravel, то соответственно тесты на авторизацию редко пишут, так как там уже готовый пакет. И в документацию эти методы не войдут, верно?
А что было с проектом, пока вы его переписывали? Бизнес же не может стоять. А если делать постепенно, то есть шанс превратить проект в некоторый франкенштейн, который также сложно поддерживать.
Вопрос работы с бд тоже довольно холиварная тема, поэтому ее и не описывал автор. Сложно будет доказать когда оправдан ActiveRecord, а когда DataMapper. И там тоже все на магии, если самому реализовывать.
Данная статья удобна для стажеров. Буду давать ее для изучение перед изучение полноценных фреймворков.
Раньше у symfony было что-то подобное в документации, объясняли все по полкам что и зачем. Как это сделать самому и как это сделано в symfony.
А вот в документации по yii вообще все грустно… Не рекомендовал бы для новичков, хотя и простой инструмент.
Вы правда так думаете? Директивный подход этого фреймворка наоборот позволяет не писать кучу кода, а использовать директивы. Интуитивно понятно же получается! Или для вас ванильный js более интуитивный из кучи строк лапши-кода?
А для простых вещей используют ванильный javascript, зачем тащить в проект библиотеку для вызова одной функции?
И я не понимаю откуда взялся этот vue,js и почему его все так пропихивают, когда есть такие шикарные инструменты, как angularJS и react + redux.
Вы серьезно? Только сейчас? В Yii2 уже давно это есть.