-
Юбилейный DevConfX пройдет 21-22 июня в Москве. Как всегда — Вы решаете, кто попадет в программу секции Backend — голосуйте за интересные доклады
Количество методов в классе, количество строк.
- Автор темы DIG
- Дата начала
Человек явно "начитался" умных слов, но даже не знает что к чему и для чего, ну так.. пыль в глаза пустить 
С.
Продвинутый новичок
Из этой темы я сформировал свое мнение. MVC в PHP имеет право быть. MVC в PHP должен быть только на активных шаблонах. Все пассивности реализуются исключительно через жопу и с фиговыми листками всяких "пейдж контролеров", которые непонятно куда приткнуть ибо они везде лишние.
Если раньше я думал, что пассивные шаблоны это просто на любителя (типа садо-мазо), то теперь я полагаю, что это в принципе ошибочно в данной среде. Собственно в этом и суть изначального вопроса ТС: куда бы мне втютюрить код, который никуда толком не подходит. Да и вообще совершенно не нужен (если изменить архитектуру). Сам вопрос, куда поместить код в контроллер или модель полностью бессмысленен, поскольку эта функциональность вообще-то должна быть в представлении.
Если раньше я думал, что пассивные шаблоны это просто на любителя (типа садо-мазо), то теперь я полагаю, что это в принципе ошибочно в данной среде. Собственно в этом и суть изначального вопроса ТС: куда бы мне втютюрить код, который никуда толком не подходит. Да и вообще совершенно не нужен (если изменить архитектуру). Сам вопрос, куда поместить код в контроллер или модель полностью бессмысленен, поскольку эта функциональность вообще-то должна быть в представлении.
caballero
Новичок
Значит хлопот от него пока больше чем пользы. Иначе бы его втыкали на всех хостингах не ожидая пока оно в ядре окажется.
Либо криво сделан и разрабы чешут репу брать его или заюзать какой нибудь xcashe.
дико извиняюсь но PHP изначально так и сделан. Если уж хочешь быть последовательным почему бы тебе не забить на акселераторы и не юзать какой нибудь hiphop-php?
я тоже берусь за серьезные задачи только теми средствами которые для этого предназначены.
Как ты себе представляешь ,например, систему обработки и архивации DICOM изображений на PHP?
Кстати другие фантазеры берут яваскрипт и делают на нем серверные приложения (к примеру продвигаемый гуглом но от этого не менее дебильный NodeJs). А чего нет? если некие умники пытаются переплюнуть яву на рынке ентерпрайз приложений почему бы нам не занять освободившееся место тоже не предназначеным для этого другим инструментом. Тем более благодатная почва - школота любит выпендрится и делать так чтобы не по уму а для понтов .
не ничего а отсутствие персистентных объектов. PHP демон и сериализация в сессионный файл сам понимаешь несколько не то. а лямбда к ООП вообще никакого отношения не имеет - это функциональное програмирование. Наведи порядок с своих мыслях.
Absinthe
жожо
PHP таки остался языком програмиирования и языком шаблонизации. А новые возможности, которые у него появились и смена архитекруты - следствие развития языка.
Вот ты раньше умел только гадить, блевать, кусать сиськи и орать - а после развития мышления и физического развития стал способен делать новые вещи, например ездить на автомобиле и срать на форумах при помощи компьютера. Так с какой стати PHP не должно пользоваться новыми инструментами и использовать новые архитекрурные решения? Чем оно хуже тебя то?
stopkran
Дилетант
А по-моему, это на чьей-то другой аве нарисовано, а отнюдь не у caballero...
Absinthe
жожо
Но в любом случае ты же в этом признался, нет?
Тогда мои посты больше не исправляй при цитировании, ок?
stopkran
Дилетант
caballero, забавно как раз, что ты НЕ наезжал на ООП. Был продекларирован наезд на МВС.
Вот здесь, почти, было уже близко. Ещё бы сказал: "обычных, статических классов" - и был бы наезд на ООП. А на МВС чего наезжать? это всё равно что наезжать на треугольник или квадрат. Видишь рисунок, на нём можно заметить квадрат. Ну и что?.. отмечаешь: "квадрат детектед", и идёшь дальше. Ну, хотя да, ты, по сути, наезжаешь не на принцип, а на людей, которые пытаются всё втиснуть в квадрат (или растянуть до квадрата). Но всё равно MVC осуждать непродуктивно: всё неизбежно скатывается к спору о терминах (всяких "пэйдж-контроллерах" и "хэлперах"). А вот наехать на ООП было бы действительно круто. Тут не надо много терминов: объект есть или его нет (одна статика), всё просто.
В другиях яхыках точно так же используются разные компиляторы или разные реализации виртуальной машины. То что он не внедряется в ядро и не стоит на всех шаред хостингах - это правда, НО из-за таких же сложностей другие языки вовсе потеряли место в этом сегменте, потому что у них проблем ещё больше.
Вот и php предназначен для задач со сложной бизнес логикой в веб сегменте, при этом вышибает конкурентов из сегмента за счёт более лёгкой и дешёвой поддержки и расширения. Nodejs так же хорошо смотрится, колеги недавно быстренько накидали скрипт на нём для разгребания очереди, который прекрасно выполняет свои функции и не требователен к ресурсам.
Да, упоминание про персистентные объекты я забыл, здесь крыть нечем, есть грех. Лябды в php это объект типа closure и он может быть прибинджен к объекту, тем самым расширяя его функционал, так что это ООП. А вот функциональное программирование это действительно с другой оперы, которая с другой стороны дороги от ООП и PHP.
caballero
Новичок
ни лямбды ни closure ни трейты ни калбэки никаким каком к ООП не относятся и относится не могут
не на MVC а на MVC паттерн котрый все пытаются заюзать а заканчивается многочисленными топиками в форумах куда мне приткнуть какой контроллер и как управлять данными
он для этого используется но не предназначен. Нет серверов приложений написаных на PHP.
Именно ентерпрайз серверов (с масштабируемостью кластеризацие и прочим)
Когда это имеет смысл (например долгоживущие объекты в VM).
Сравни скорость компиляции страницы без акселератора с акселератором и сравни это все с временем загрузки страницы юзеру. Сомневаюсь что юзер заметит что его сайт стал грузится на сотую долю секунды быстрее.
Для монстров типа жумлы и битрикса нужны акселераторы и кешеры иначе оно шевелится не будет но для вменяемых решений акселератор выгоды пока не приносит. Разумеется если разрабы PHP натыкают в язык еще десяток малополезных плюшек то тогда и обычная страница без акселератора работать не будет.
Если конструкция позволяет добавлять функционал к объекту и менять его состояние, то это однозначно ООП.
мы вроде о бизнес логике говорили, а вы полезли в кластеризацию.
Во первых, apc не является акселератором, т.к. просто хранит результат генерации опкодов для виртуальной машины, но никак не ускоряет сам код. Акселератор, это наверное Zend Optimizer, если его ещё делают, но им никто особо не пользуется. Во вторых, практически все языки имеют оптимизаторы и хранят результаты компиляции, почему для php это преступление?
caballero
Новичок
вообще то мы говорили об ентерпрайз приложениях. Это не битрикс и не зенд и то что на них написано или будет написано.
Ентерпрайз это к примеру Oracle Application который пришлось немного юзать - только таблиц в БД около пяти тысяч.Это конечно
патологический случай а вообще ентрепрайз системы это типа WebSphere или WebLogic полноценные (начиная от веба заканчивая драйверами распределенных транзакций) системы без внешних примочек способные потянуть десятки и сотни тысяч юзеров.
Но таких приложений доли процента - остальное - обычные сайты. Поэтому PHP и рулит и не надо пытатся с него делать то что сделать не получится.
Однозначно не ООП. Мало ли что позволяет там чего добавлять.
ООП - это без чего парадигма не может обойтись. А обойтись ООП может даже без наследования и полиморфизма.
Mols
Новичок
Первая строчка в топике
В общем у меня с этим дела обстоят так.
1. Если любой класс перешагивает 400-500 строк это повод посмотреть его на предмет декомпозиции. (именно посмотреть но не сделать любой ценой)
2. Если экшен в контроллере становится больше 5-10 строк это повод подумать над созданием сервиса (опять же подумать, а не сделать любой ценой)
В результате получается что-то типа.
У объекта передаваемого в представление уже есть все данные которые требуются представлению.
или так.
Здесь в представление идет ассоциативный массив.
В любой момент мы можем добавить любое новое представление для этих данных.
Здесь сейчас жсон и хмл. Можем сделать более удобочитаемое для человека - ноль проблем.
хотите ещё одни вьюв для арабов, чтобы справа налево - нет проблем.
Ещё один экшен + любой вьюв. Который желаете.
Дык что нефиг гнать. MVC вполне используется и вполне по назначению (но помним, что это веб).
Пользуйтесь где удобно, где не удобно - не пользуйтесь.
MVC - Это логическое разделение кода.
И это разделение требует постоянной оценки на месте.
Всегда надо думать куда и как разместить код.
Например делать сервис или нет. Если делать, то что должно войти в этот сервис, что в другой и т.д.
Теперь чуток ещё.
Так уж сложилось, что где-то с год работаю с Флекс и С# чуть-чуть Java
PHP как-то отошел.
Дык хочу сказать, что эти же вопросы приходится решать и там.
Серебрянной пули нет.
И всегда надо думать, что и куда определить.
Хотя конечно Java и C# после PHP это как бальзам на душу)))
Очень приятные и удобные инструменты.
И если человек писал нормальный опрятный, дисциплинированный и грамотный код на PHP, то с этими технологиями работать - просто песня.
Дык что хорош шашками махать)))
Пусть будет ничья)))
И уже 8 страниц обсуждений)))
В общем у меня с этим дела обстоят так.
1. Если любой класс перешагивает 400-500 строк это повод посмотреть его на предмет декомпозиции. (именно посмотреть но не сделать любой ценой)
2. Если экшен в контроллере становится больше 5-10 строк это повод подумать над созданием сервиса (опять же подумать, а не сделать любой ценой)
В результате получается что-то типа.
PHP:
.....
public function routerAction()
{
$this->view->oService_Kladr_AddressRouter = new Kladr_Service_AddressRouter($this->getRequest()->getParam('code', ''));
}или так.
PHP:
....
protected function runService()
{
$this->view->oData = Kladr_Service_Api_Execute::auto($this->getRequest());
}
public function xmlAction()
{
$this->runService();
}
public function jsonAction()
{
$this->runService();
}В любой момент мы можем добавить любое новое представление для этих данных.
Здесь сейчас жсон и хмл. Можем сделать более удобочитаемое для человека - ноль проблем.
хотите ещё одни вьюв для арабов, чтобы справа налево - нет проблем.
Ещё один экшен + любой вьюв. Который желаете.
Дык что нефиг гнать. MVC вполне используется и вполне по назначению (но помним, что это веб).
Пользуйтесь где удобно, где не удобно - не пользуйтесь.
MVC - Это логическое разделение кода.
И это разделение требует постоянной оценки на месте.
Всегда надо думать куда и как разместить код.
Например делать сервис или нет. Если делать, то что должно войти в этот сервис, что в другой и т.д.
Теперь чуток ещё.
Так уж сложилось, что где-то с год работаю с Флекс и С# чуть-чуть Java
PHP как-то отошел.
Дык хочу сказать, что эти же вопросы приходится решать и там.
Серебрянной пули нет.
И всегда надо думать, что и куда определить.
Хотя конечно Java и C# после PHP это как бальзам на душу)))
Очень приятные и удобные инструменты.
И если человек писал нормальный опрятный, дисциплинированный и грамотный код на PHP, то с этими технологиями работать - просто песня.
Дык что хорош шашками махать)))
Пусть будет ничья)))
caballero
энтерпрайз - это приложение предназначенные для ведения бизнеса и документооборота, для php там есть место: crm, erp, платёжные системы, автоматизация и статистика, saas.
энтерпрайз - это приложение предназначенные для ведения бизнеса и документооборота, для php там есть место: crm, erp, платёжные системы, автоматизация и статистика, saas.
бугагашенька, у них даже свои патчи поверх стандартной JAVA, а вы тут слюной исходились из-за использования стандартной библиотеки в php.