Мне кажется автор не понимает одной вещи: Фаулер сотоварищи пишут о энтерпрайзной разработке. Т. е. о длительной многолетней командной разработке в условиях постоянно меняющихся требований и накапливающегося технического долга.
Большая часть пхп-разработки — это короткие разовые проекты, выполняемые одним фрилансером. Ну вот зачем ему di для разработки сайта-визитки, которую он напишет за день, сдаст и забудет? Естественно народ не понимает зачем ему это все надо.
Да и что вы хотите от языка, если он сам и библиотеки построены с нарушениями общепринятых best practices и вообще уродливы?
Если хотите красивого кода — то переходите туда, где он востребован — в дотнет или джаву, в долгосрочные проекты.
А ведь еще есть следующие ступеньки — например, метапрограммирование в Ruby, листе или пятом шарпе
> Теперь наш сайт имеет дерево, кучу вкладок, форму, несколько тулбаров и т.д. Таблицы, что вставлены во вкладки,
> сортируются во все направления. А поле Аватар в форме может без перезагрузки всей страницы загружать и удалять
> картинку. Так как же организовать запросы ко всем этим элементам?
Долго думал, что такое «текучий интерфейс». Fluent interface что ли? А почему он расширенный?
А вы в курсе, что interface в выражении «fluent interface» и «интерфейс» в «интерфейс пользователя» — это разные вещи?
А вообще, вы изобрели Domain Model и зачем-то смешали его с отображением, нарушив single responsibility principle.
Fluent interface — это, мягко выражаясь, другое.
> 1. разделение на базы не позволяет установить все взаимосвязи между данными и, соответственно, это не дает
> выжать из них всю пользу.
> 2. программа получившая контроль над какими-либо данными не имеет интереса дальше оптимизироваться по
> отношению к ним, пользуясь своим монопольным положением.
Это к тому, что вы очень сильно преувеличиваете проблему, которая конечно существует, но решения разрабатываются и в этом занято очень много людей.
Поэтому более вероятная картина (имхо) — множество интегрированных друг с другом локальных баз и, да, агенты-майнеры (которых вы называете мультами).
А вот дальше, совсем непонятно, как именно это может привести к повсеместной роботизации и вообще у вас дальше идет типичная НФ про ИИ уже много раз обсуждавшаяся.
Проблема в том, что РЕАЛЬНЫЕ проблемы ИИ они мягко выражаясь совсем другие, чем в НФ.
> Сегодня роботы тотально проигрывают по эффективности людям. Любой восточно-азиатский рабочий
> производительнее и удобнее самых совершенных из нынешних автоматов. Их КПД несопоставимы.
Ошибка. Проблема в том, что разработка и внедрение промышленного робота — это дорого, а китайцев — много и они готовы работать совсем дешево, при этом далеко не всегда обеспечивая качество. КПД уже внедренного робота в разы лучше, чем у китайца.
Плюс есть политические проблемы — куда девать ораву необразованных рабочих, если робот лишит их работы?
Тем не менее, рано или поздно все производство будет автоматизировано.
> Единственная причина наличия роботизированных линий в таких условиях — временные военно-финансовые
> завоевания ряда развитых государств, позволяющие их гражданам щедро проплачивать избавление от
> физического труда.
Ни в коей мере не защищая автора, все же замечу что его идеи вполне можно реализовать на базе мультиагентной системы. И если каждого агента назвать «нейроном», то получится «нейронная сеть». Правда действительно не имеющая никакого отношения к тому что принято называть ИНС.
Про одну из реализаций можно почитать по ссылкам в моем комментарии
Это означает, что вы неправильно понимаете, что означает stateless.
Смотрите, пусть есть некий черный ящик со входами и выходами, причем входами являются: входные данные, которые передает пользователь и некие бизнес-данные из внешних по отношению к сервису источников (база данных). Выходными данными является результат некоей обработки входов.
Тогда:
stateless-сервис будет всегда выводить на выход одни и то же значения при одних и тех же значения на входах
statefull-сервис имеет некую внутреннюю память (состояние) и выход зависит не только от текущих значений входа, но и от того что было на входах ранее.
После обсуждения с коллегами и вкуривания в «SOA Designs Patterns» Томаса Эрла пришли к такому выводу:
То что авторизационный токен передается отдельно от других входящих параметров, не означает, что токен не входит в множество входящих параметров. Бизнес-логика сервиса естественно может зависеть от параметров, в том числе и от параметра «залогинившийся пользователь».
Соответственно, мой вариант сервиса вполне имеет право на существование, а ваш — все-таки решает немножко другую задачу (у вас два запроса — один на получение всех пользователей, второй — на получение пользователей конкретного отдела).
Ок.
Пример из коммента выше со списком пользователей системы:
Юзер Вася директор филиала и может видеть только пользователей своего филиала.
Юзер Дима админ всея системы и всегда видит всех пользователей системы.
В итоге, сервис один, он все равно stateless, но вывод функции зависит от того какой пользователь делает запрос.
Просто надо понимать, что есть:
1. Входные данные
2. Некие бизнес-данные
3. Некие данные о состоянии самого сервиса.
И пока данных о состоянии сервиса нет и они не влияют на его поведение — сервис остается stateless.
Грубо говоря:
Если сервис возвращает, например, список пользователей, но после 100-го запроса внезапно переключает некий флаг и начинает возвращать список пользователей с каким-нибудь фильтром или вообще какой-нибудь другой список — то это stateful service.
Если же он всегда возвращает список пользователей, но при этом кол-во пользователей в системе меняется и результат запроса естественно тоже меняется, то это не мешает сервису быть stateless.
Большая часть пхп-разработки — это короткие разовые проекты, выполняемые одним фрилансером. Ну вот зачем ему di для разработки сайта-визитки, которую он напишет за день, сдаст и забудет? Естественно народ не понимает зачем ему это все надо.
Да и что вы хотите от языка, если он сам и библиотеки построены с нарушениями общепринятых best practices и вообще уродливы?
Если хотите красивого кода — то переходите туда, где он востребован — в дотнет или джаву, в долгосрочные проекты.
А ведь еще есть следующие ступеньки — например, метапрограммирование в Ruby, листе или пятом шарпе
> сортируются во все направления. А поле Аватар в форме может без перезагрузки всей страницы загружать и удалять
> картинку. Так как же организовать запросы ко всем этим элементам?
Откройте для себя REST-архитектуру.
А вы в курсе, что interface в выражении «fluent interface» и «интерфейс» в «интерфейс пользователя» — это разные вещи?
А вообще, вы изобрели Domain Model и зачем-то смешали его с отображением, нарушив single responsibility principle.
Fluent interface — это, мягко выражаясь, другое.
> выжать из них всю пользу.
> 2. программа получившая контроль над какими-либо данными не имеет интереса дальше оптимизироваться по
> отношению к ним, пользуясь своим монопольным положением.
Как бы никто не отменял это, вот это
Это к тому, что вы очень сильно преувеличиваете проблему, которая конечно существует, но решения разрабатываются и в этом занято очень много людей.
Поэтому более вероятная картина (имхо) — множество интегрированных друг с другом локальных баз и, да, агенты-майнеры (которых вы называете мультами).
А вот дальше, совсем непонятно, как именно это может привести к повсеместной роботизации и вообще у вас дальше идет типичная НФ про ИИ уже много раз обсуждавшаяся.
Проблема в том, что РЕАЛЬНЫЕ проблемы ИИ они мягко выражаясь совсем другие, чем в НФ.
> Сегодня роботы тотально проигрывают по эффективности людям. Любой восточно-азиатский рабочий
> производительнее и удобнее самых совершенных из нынешних автоматов. Их КПД несопоставимы.
Ошибка. Проблема в том, что разработка и внедрение промышленного робота — это дорого, а китайцев — много и они готовы работать совсем дешево, при этом далеко не всегда обеспечивая качество. КПД уже внедренного робота в разы лучше, чем у китайца.
Плюс есть политические проблемы — куда девать ораву необразованных рабочих, если робот лишит их работы?
Тем не менее, рано или поздно все производство будет автоматизировано.
> Единственная причина наличия роботизированных линий в таких условиях — временные военно-финансовые
> завоевания ряда развитых государств, позволяющие их гражданам щедро проплачивать избавление от
> физического труда.
тынц
Экономику комментировать не буду, ибо не разбираюсь в достаточной мере в вопросе.
А если серьезно — я тоже такую траву хочу.
Если совсем серьезно — вы, мягко выражаясь, «не в теме».
Вы вот это не читали?
Про одну из реализаций можно почитать по ссылкам в моем комментарии
статья в вики
книжка от автора
Смотрите, пусть есть некий черный ящик со входами и выходами, причем входами являются: входные данные, которые передает пользователь и некие бизнес-данные из внешних по отношению к сервису источников (база данных). Выходными данными является результат некоей обработки входов.
Тогда:
stateless-сервис будет всегда выводить на выход одни и то же значения при одних и тех же значения на входах
statefull-сервис имеет некую внутреннюю память (состояние) и выход зависит не только от текущих значений входа, но и от того что было на входах ранее.
Почитайте про конечные автоматы, понятнее будет ;)
То что авторизационный токен передается отдельно от других входящих параметров, не означает, что токен не входит в множество входящих параметров. Бизнес-логика сервиса естественно может зависеть от параметров, в том числе и от параметра «залогинившийся пользователь».
Соответственно, мой вариант сервиса вполне имеет право на существование, а ваш — все-таки решает немножко другую задачу (у вас два запроса — один на получение всех пользователей, второй — на получение пользователей конкретного отдела).
Пример из коммента выше со списком пользователей системы:
Юзер Вася директор филиала и может видеть только пользователей своего филиала.
Юзер Дима админ всея системы и всегда видит всех пользователей системы.
В итоге, сервис один, он все равно stateless, но вывод функции зависит от того какой пользователь делает запрос.
1. Входные данные
2. Некие бизнес-данные
3. Некие данные о состоянии самого сервиса.
И пока данных о состоянии сервиса нет и они не влияют на его поведение — сервис остается stateless.
Грубо говоря:
Если сервис возвращает, например, список пользователей, но после 100-го запроса внезапно переключает некий флаг и начинает возвращать список пользователей с каким-нибудь фильтром или вообще какой-нибудь другой список — то это stateful service.
Если же он всегда возвращает список пользователей, но при этом кол-во пользователей в системе меняется и результат запроса естественно тоже меняется, то это не мешает сервису быть stateless.
> В теории очень правильно.
Т.е. любой сервис, который возвращает мне результат некоего запроса к БД, которая может изменяться — это уже stateful-сервис?
> Логин-пароль или токен при этом не считаем входными данными.
А чем мы их считаем?