0. Я не считаю верхом мастерства ООП и не говорил этого. Высосано из пальца.
1. Терпеть не могу когда отвечают как вы, то есть не отвечают. Человек не спрашивал любить ООП или нет, он недоумевает как использовать приобретенные знания.
2. Не думаю, что Вы в каждом новом проекте все пишете с нуля, есть наработки которые таскаете за собой, это и есть фреймворк. Ваш личный, но фреймворк.
3. Бизнесу срать как и что вы пишете, но не срать на ЗП сотрудников и скорость реализации.
Еще бизнесу надо, что бы новый сотрудник сел и работал, а не разбирался пол года, что и как работает. На фрилансе, когда один делает, другой поддерживает это еще критичнее.
4. Не точно выразился, если Вы пришли в проект, и там используют ту же симфони, то Вам с ходу понятна архитектура проекта. Задает в этом плане.
5. Никто не запрещает подключить другую ОРМ взамен AR.
----
ЗЫ. К Вам ваши слова относятся точно так же. Вы с другой стороны баррикады, но такой же убежденный в своей правоте. Слепо верите, что AR зло, что надо тоньше, что ООП не надо.
И даже не думаете, о том, что все зависит от задач и от проекта.
ЗЫЫ.
Цитата:
Да, ****, **** и в продакшн.
Да уж лучше стонать "Дайте денег, я работал. сматрите какую табличку нарисовал". Делал минутную задачу несколько часов и просрал, денег больше чем заработал, вот что это.
1. Это соглашения которых придерживается сообщество фреймворка.
т.е. если вы попадете в другой проект где так же используется симфония будет сходу понятно, что где лежит и что как работает(в большей своей массе)
2. На первых парах делаем так: Задаем вопрос гуглу "Symfony что-то там". например
"Symfony валидация связанных моделей при сохранении"
читаем, что там люди пишут.
3. На самом деле фреймворк это куча проделанной работы которую можно использовать.
Например можно писать свой роутер для чпу, а можно юзать фрейм и там чпу будет работать из коробки. Или скажем аутентификация пользователей, или RBAC, или модели. Причем фишка в том, что еще будут какие-нибудь виджеты в слое представления которые будут работать с этими моделями(или провайдерами) из коробки. Сунул посты в GridWidget получил список. Делов на минуту.
4. фрейм задает архитектуру проекта, костяк.
5. Нестандартные задачи это хорошо. Только не понятно. Возможно Вы еще не знаете как это решается в выбранном вами фрейме. гуглим и будет счастье.
---
PS. Сам пишу с использованием Yii. Единственная нестандартная задача за все время, которую реально было геморно реализовывать это UNION. Его нет в ActiveRecord Yii.
ну а представление это набор шаблончиков:
views/post_page.php
[HTML]
<small><?php $model->created; ?></small>
<h4><?php echo $model->title; ?></h4>
<p><?php echo $model->body; ?></p>
[/HTML]
Ну опять таки недостаток примера который Я привел.
Ладно, что бы было проще, это Yii way. На самом деле за findBy... нет прямой выборки из базы, там обращение к CCommandBuilder который по сути и является ресурсом или типо того.
это на самом деле и есть модель Order
заполненная данными из нескольких таблиц
и представляющая самый настоящий объект реального мира, но не отдельную таблицу
Я бы не стал все это в кучу пихать, работать будет не удобно. Если мне нужны будут только orderItems Я не смогу их получить без самих ордеров.
К примеру мне нужен отчет по продажам продукта, выбрать из базы просто, а модели представляющей итемы отдельно нет.
Если бы итемы были просто связью многие ко многим, то да нет смысла модель заводить, но в примере выше они еще хранят количество заказных продуктов(еще там может быть денармолизована стоимость_продукта * количество, какой-нибудь статус, и т.д.).
ну если по стандартам psr, то да! Если по работоспособности кода, то нет!
Обязательно. Вы не объявили массив, Ваш интерпретатор Вам это простил. Отдали код заказчику, а там на сервере E_ALL и display_errors, на сайте заказчика нотис.
Он(Заказчик) думает, что это ошибка(онжнепрограммист) и дает Вам "по шапке", т.к. Вы дали ему не рабочий(с его точки зрения) код.
----
решил упростить (Добавление)
А вообще зависит от ситуации.
Если что-то надо сделать с данными из одного объекта то смело делаем метод как в примере выше.
Если Есть кучка объектов(например Order, OrderItem, Product) они связаны между собой и надо что-то считать основываясь на всех трех объектах, то лучше сделать отдельную модель членами которой будут эти объекты и методы работы с ними.
Это вот фигово, что в статьях и книгах объекты стараются сопоставить с "объектами реального мира", потом проблемы у людей возникают. (Добавление)
Вы меня извините, но это реплика "неосилятора" и новичка. Фреймворки значительно облегчают разработку.
Я прям вижу как Вы мучаетесь, пишете одно и тоже раз за разом, а потом
создаете тему "Своя CMS" или что-то подобное, где пишете, что все существующее какашка, а вот Ваше творение реально "крутяк".
не надо так...