Реализация MVC подразумевает обработку только одной выбранной записи?
Подход в Yii меня не очень радует AR, чтобы удалить запись ее сначала надо вызвать, а потом уже что то с ней сделать.
Relations правила Yii это тоже странная связь моделей, где по одной записи я не могу связать join, мне надо будет выполнить 150 MVC связей(образно).
Сама идея MVC меня привлекла разделением логики и представления информации, в данной ситуации мне не нужен велосипед, хотел бы получить возможность решения данных вопросов:
1) как реализовать удаление, вызов и обработку массива данных, а не зацикливать на повторении с каждой записью;
2) так же как связать данные из разных таблиц.
Мысль вынести это в отдельную модель(Service Layer), в которой можно собрать обработку большого количества записей и сразу в ней же реализовать связь между таблицами, возможно наборами join и прочего.
Судя по вашему вопросу, вы неправильно трактуете идею MVC либо же путаете MVC и ORM.
MVC ничего не регламентирует по поводу того, как вам работать с данными. Этот паттерн подразумевает лишь разделение вашей бизнес-логики (данные и обработка оных) и представления посредством промежуточного слоя контроллеров.
То как хранятся данные слабо относится к бизнес-логике, это обычно выносится в сервисный слой. И тот же yii не ограничивает вас в чем-быто нибыло. Вы можете не использовать ar вообще, можете заменить на data mapper (с использованием doctrine). Скажем ваши данные вообще ничего не должны знать о том как они хранятся, об этом даже контроллеры не особо то должны быть вкурсе. Обычно для этого вводят промежуточный слой работающий с данными и инкапсулирующий всю логику по сохренению/удалению записей. Это уменьшает связанность системы и удешевляет дальнейшую поддержку приложений.
Вот я и хочу разобраться. Одна модель MVC имеет возможность общаться с базой как ей угодно не важно какие связи и таблицы, она только разделяет.
Значит Yii фреймворк жестко ограничивает M модель назначая ей AR, что приводит к тому, что одна модель работает только с одним типом модели данных, указывая ей на область работы.
Что приводит к путанице, когда модель может общаться с базой как ей угодно.
Вопрос, не нарушает ли это концепцию ООП, когда мы путем объявления классов, стараемся уйти от повторений.
@CoolerMan любопытно узнать откуда вы услышали этот слух... Вы можете привести аргументы против? Как по мне один жирный класс который может все это не очень хорошо.
По поводу функционала yii - из того что вы описали как я понимаю, у вас не так много опыта работы с этим фреймворком. Скажем те ограничения которые вы описали, следствие не знания того что можно делать в yii.
Если вы хотите соблюдать базовые принципы ООП то вам нужен не active record а data mapper. С ar в контексте yii это не возможно, так как у вас один класс знает и про валидацию, и про хранение в базу и т.д. что не есть правильно.
Вот, что я и хотел подтвердить. Сижу несколько дней, разобрал Yii и в конце пришел к выводу, что это вещь, как фабрика для кроликов, сплошная статика и вывод по одной странице.
Хотя опять же Symfony не совсем MVC. Как говорит его создатель Фабьен:
"I don't like MVC because that's not how the web works. Symfony2 is an HTTP framework; it is a Request/Response framework."
Да, тут я согласен с Fabien. MVC похожа для реализации desktop приложений, но сама суть описывает именно то что мне надо, то есть MVC это то к чему я пришел из требований к проекту.
@Fesor Вот и хочу понять правильную идеологию Model, все пишут, что модель создана для работы с базой, что по сути просто разделяет наш код на 3 части и не мешает их. Да само по себе это лучше воспринимается.
MVC это как раздел того, что я хочу сделать с определенными запросами.
Точно не ошибочно предполагать, что каждый pattern будет работать независимо от другого?(ссылаясь на одинаковые таблицы, но выполняя разные действия)
@CoolerMan почитайте про DDD, там конкретно говорится что такое доменная модель и вам не нужно будет путаться во всех этих условностях. MVC сейчас довольно расплычтаное понятия. Главное просто писать слабо связанные системы.
Простой
