Насколько код ООП и что бы вы посоветовали по его улучшению?

Николай: на стэковерфлоу и на реддите не так давно проскакивала идеи инициативы, по удалению/пометке "плохо не надо так делать" всех ресурсов, старых статей, обсуждений в форумах и т.д. по PHP которые учат плохому.... интересно было бы глянуть на мир где вся та грязь будет заклемена... насколько улучшится мир.

Насколько код ООП и что бы вы посоветовали по его улучшению?

dk-web: да, извините. Я наискосок читаю, некоторые слова выпускаю извиду...

Насколько код ООП и что бы вы посоветовали по его улучшению?

Николай: а... вы про pdo/password api, ну тут да... с учетом миллионов статей написанных 10 лет назад непонятно кем, которые учат как плохо... да это проблема.

Насколько код ООП и что бы вы посоветовали по его улучшению?

dk-web: новшества это только для PHP разработчиков которые застали PHP4 и проспали 10 лет в неведеньи.

Насколько код ООП и что бы вы посоветовали по его улучшению?

dk-web: новшества? Шаблоны проектирования придумали 20 лет назад! 20! Принципы Object-oriented design описали 25 лет назад.... новшества...

Где можно посмотреть пример готового сайта на Express.js?

copal: еще у меня есть такая забавная мысль, что весь наш спор и выеденного яйца не стоит. MVC было придумано 35 лет назад с учетом тех реалий. Напомню, примерно в то время эпл и майрософт повзаимствовала у ксерокс все их наработки. С тех пор появилась куча адаптаций MVC под современные реалии усложщяющихся интерфейсов и больших объемов данных с которыми приходится работать. во фронтэнде сейчас доминирует HMVC а не чистый MVC. Да и на сервере. А тот MVC который придуман 35 лет назад... ну он дал основную идею, а дальше - развитие.

Короче принципы SOLID как по мне намного важнее чем загоны аля "MVC это или не MVC". Сейчас это не архитектура приложения, это архитектура UI максимум. Архитектура самого приложения имеет слой абстракций что бы полностью изолироваться от интерфейса, при помощи которого мы работаем с приложением. И это главное, абстракция. Что бы можно было изолировать основную часть нашего приложения, бизнес логику, бизнес правила, бизнес объекты. Что бы контроллеры оставались тонкими, что бы view layer вообще ничего не знал о наших бизнес объектах, пусть transfer object-ы кушает.

Вот...

Где можно посмотреть пример готового сайта на Express.js?

copal: в angular2 вообще ввели абстракцию от DOM как и в reactjs.

Где можно посмотреть пример готового сайта на Express.js?

copal:

это теория рассказывающая, как должны связываться части приложения.

Не части нашего приложения, а части отдельного компонента UI (не кнопка конечно, но скажем форма редактирования чего-то).

Давайте все же определимся. Помниться месяц-два назад вы мне скидывали ссылки на оригинальные статьи/сканы переписок/публикации 79-ого года о MVC. Вопрос был в том что бы это дело перевести и опубликовать (я к слову сегодня всерьез задумался об этом). Я их даже почитал, особенно ту часть которая описывает что такое модель, что такое контроллер и что такое view.

Так вот, мы все еще говорим о том самом MVC которому уже 35 лет? Точно? Потому что мне как-то кажется что нет.

Давайте так, на бэкэнде нет MVC потому что:

- нет обзервабл связей между моделью и представлением
- контроллер как правило знает о представлении (чего он знать не должен, его задача простая - обработать ввод данных пользователя)
- модель, согласно документам 79-ого года, должна быть либо одним объетом, либо структурой, объедененной ассоциацией один-к-одному (то бишь дерево). И все было бы хорошо если бы мы делали aggregate root или что-то в этом духе, хранили бизнес логику в сущностях и пихали их во view. Тогда правила бы сохранялись.
- одна модель (или его часть) должна иметь одно или больше представлений.

Что же мы видим в типичном RoR приложении и приложениях на RoR-like фреймворках? В тех самых "правильных" MVC фреймворках? Люди пихают несколько моделей в одну view, у нас как правило одна жирная view на всю страницу! То есть один view для всех моделей задействованных для отрисовки одной страницы!

Вы видите разницу? На фронтэнде с этим проще, там UI дробится на компоненты, как правило у каждой модели есть маленькое view и маленький контроллер, контроллер ничего не знает о view, view связано с моделью обзервабл связью... то есть все как в той доке которая была опубликована 35 лет назад! И самое забавное что пришли к этому относительно недавно, а некоторые еще идут.

но я и не говорю об архитектуре, которая убога как например в angular

У ангуляра (если мы берем версию 1.4+) все относительно неплохо с архитектурой. При использовании компонентного подхода, при дроблении UI на директивы, каждая директива становится маленьким MVC приложением. То есть это именно то что нужно. Да, React в этом плане более правильный, так как он позволяет меньше непотребств. Благо в angular2 все с архитектурой хорошо и почти все что позволяло сделать плохо выпилили.

А вот если мы возьмем скажем RoR... что нам дает RoR? возможность организовать DAO + HTTP/CLI интерфейс. И все. Больше ничего. Все остальное - good old plain ruby, наше приложение. Никакого MVC внутри (у нас там нет ни представлений ни контроллеров). И это не модель в контексте MVC. Это штука которая возвращает модель по требованию. Возможно это будет "модель" в контексте active-record, а не православный transfer object. Возможно мы даже уподобимся сделать aggragate root и вернуть только ее а не пачку каких-то моделей, но что-то я сомневаюсь.

Если MVC это клей, то почему спустя 35 лет люди продолжают писать бизнес логику в контроллере? Может быть... люди слишком долго нюхают этот клей?

Дядя боб рассказывает про MVC и встречу в Осло с автором этой "архитектуры": видео. Посмотрите, там буквально пару минут.

Короче мое ИМХО:
- MVC это GUI архитектура, которая применима только для организации GUI. Для всего остального есть другие вещи. А на бэкэнде вместо контроллера в контексте MVC обычно используется GRASP-ский контроллер, задача которого транслировать асинхронные запросы пользователей в синхронные запросы к системе.

Считать что MVC это клей который связывает все это глупо. Нельзя описать "все" тремя компонентами с двумя стрелочками.

Что такое "отказ от двустороннего датабиндинга"?

lega: да как бы так же реализовано примерно и в angular, что бы не допускать рекурсии на пустом месте.

ну насчет маркетинга - пожалуй, ибо... он в angular2 таки остался, во всяком случае можно все так же работать с ng-model. Внутри механика поменялась на односторонний байндинг + ивенты, а снаружи все же все чуть прозаичнее. Но я пока не особо ковырял второй ангуляр так что помолчу.

А вот дебаг логики завязанной на ватчеры, на двусторонний байндинг в директивах... вот этого я нахлебался на суппорте проектов (да и первый год с ангуляром так же фигачил). Очень легко превратить систему в неподдерживаемое мессиво если она хоть сколько нибудь большая, если у тебя данные меняются где хотят.

Что такое "отказ от двустороннего датабиндинга"?

Сергей: обновил ответ.

В общем идея такая, двусторонний дата биндинг позволяет любому объекту поменять состояние любого объекта. Причем никаких ограничений, просто все связанные проперти объектов всегда будут равны. Если вам надо как-то реагировать на изменение данных внутри будут ивент листенеры и т.д. С другой стороны можно сделать метод меняющий данные у объекта и односторонний бидинг для связи. В этом случае зависимый компонент будет связан односторонним дата бингингом, и если он захочет поменять значение то он попросит об этом компонент, а тот, если поменяет на то что мы просили (вдруг это нарушает бизнес логику), поменяет значение своего свойства, и изменения подтянуться за счет одностороннего биндинга.

Если же другой компонент просто поменяет пропертю, это не нарушит работу связанных объектов. Они затрут изменения при первой синхронизации.

Где можно посмотреть пример готового сайта на Express.js?

copal:
в правильном mvc кнопка это представление.
в правильном MVC кнопка это кнопка. Она может не быть частью представления модели, это может быть просто кнопка, механизм ввода. Пользователь тыкает на кнопку, контроллер обрабатывает клик и говорит модели что делать. Причем кнопка ничего не знает о модели, а модель ничего не знает о том кто попросил и каким способом сделать то что оно сделало.

Пример с поросенком и овечкой не показательный, у меня по нему не выходит проследить ваш поток мыслей.

Короче пока я только убедился в том что я правильно понимаю концепцию MVC, так как вы говорите о том же о чем и я, вот только у меня фокус не на MVC, в моем мире MVC это GUI архитектура, а GUI отделено от приложения, от бизнес логики, это всего лишь ввод/вывод информации. Подумайте над этой проблемой в контексте CLI, попробуйте применить MVC к CLI скриптам. Или например MVC к обработчикам MQ. У вас получится что-то неповоротливое и большое.

И еще я понял что в вашем представлении есть такие вещи как MVC фреймворки (мне не понятно что это такое, MVC фреймворк, как по мне это все маркетинговый булшит, если мы говорим про бэкэнд), я еще понимаю MVC библиотека для более удобной организации компонентов UI, такие как React или тот же Angular2, но опять же, это отдельные библиотеки. И фреймворк в моем представлении это только набор библиотек и не более. Слой абстракций. Фреймворк удобен только тогда когда его компоненты можно заменять в случае ситуации которую не покрывает этот фреймворк.

словом из ваших комментариев пока у меня складывается впечатление что у нас выходит некое недопонимание. Я погорячился когда сказал что MVC это не архитектура, но это не архитектура самого приложения. В целом саму концепцию мы воспринимаем одинаково, но у вас слишком часто проскакивают "фреймворки" и прочая чушь. Я не знаю как вы это связываете вместе, более того я считаю что вы считаете фреймворки краеугольным камнем, фундаментом приложения. Я же считаю что приложение должно быть полностью изолировано от фреймворка, предоставляя интерфейсы, которые реализуются с применением компонентов фреймворка.

Продолжение в личку. Мне реально интересно разобраться.

Где можно посмотреть пример готового сайта на Express.js?

copal: и да, посмотрите видео: https://www.youtube.com/watch?v=0oGpWmS0aYQ

дядя боб намного лучше формулирует мысль чем я.

Где можно посмотреть пример готового сайта на Express.js?

я написал целую гору писанины но решил удалить... вместо этого сокращу до следующих пунктов:

- уговорили, MVC это GUI архитектура и точка, это не архитектура всего приложения, более того к самому приложению это никакого отношения может не иметь.
- пример с кнопкой - я не так пожалуй выразился. Имелось в виду что для кнопки можно сделать отдельный контроллер который будет говорить модели что надо делать. Кнопка ничего не знает о представлении или может быть частью одного из представлений модели или его части.
- фреймворк не скелет приложения, это не его опора. Это второстепенная фигня, набор готовых решений часто встречающихся проблем, набор абстракций и только. Наше приложение не должно зависить от него, наоборот, мы должны выстроить между фреймворком и приложением стену. Но не надо понимать это как призыв к отказу от фреймворков - наоборот, надо знать их место. Это просто инструменты.
- на бэкэнде нет места классическому MVC так как это GUI архитектура. Ему есть место только в контексте реализации UI-layer приложения.

Пусть Вы даже стремный код напишите, но правильный mvc фраймворк поможет создать работающие приложение.

полнейший бред.

Где можно посмотреть пример готового сайта на Express.js?

copal: вообще пишите в личку, мне было бы интересно этот вопрос обсудить с вами и придти наконец к какому-то разумному консенсусу. Но дядю боба (то что я в ответе привел) посмотрите.

Java время компиляции и TDD?

а как вы собираете проект?

Где можно посмотреть пример готового сайта на Express.js?

copal: да насмотрелся дядю Боба (и вы посмотрите). Меня всегда смущало MVC в контексте WEB потому что... ну потому что ни о чем. Когда люди начинают трактовать такие примитивные и базовые вещи кто как захочет - значит что-то не так. Если даже почитать статьи что вы предлагали перевести - то там все очень даже просто. Есть ввод данных (controller), есть их вывод (view) и есть их обработка (model). Все. Причем никто и никогда в те времена не делал одну вьюху на скрин или один контроллер на скрин - все дробилось на элементы и для каждого была своя модель, свой контроллер, свое view. На фронтэнде, на UI, все к этому снова и идет (Angualr2, React), поток данных только в одну сторону (отказ от двустороннего датабиндинга, только односторонний), дробление UI на отдельные компоненты со своей моделью, контроллером и представлением. Маленькие масштабы, схема работы с данными, не архитектура.

Да даже если брать бэкэнд классический с html и т.д. тот самый HMVC конечно еще подходит (когда мы дробим UI на маленькие элементы для каждого из которого есть свои модели и свои контроллеры) но в случае с web api все чуть сложнее, так как тут дробить view не выйдет. У нас тупо сериализация данных, и все. То есть весь view сводится к мэппингу данных и сериализации. Ну и опять же это все только определяет как у нас разделено приложение и регламентирует направление потока данных (строго в одну сторону).

Словом MVC это не архитектура, это правило описывающее поток данных и разделение ответсвенности. CQRS чуть ближе походит на архитектуру, хотя опять же это несколько не то. Это абстрактное правило, бэст практис и только.

makes sence или я упорот?

Что такое тяжелая и легкая задача для потока?

beduin01: ну ничего, как только файбер Б сделает свой кусок задачи то файбер А начнет делать дела.

По поводу "как сисема определяет кто что просил" - за каждым ресурсом закреплен дескриптор (файла, сокета) и таким образом система разруливает все. Грубо говоря сам поток или хэндер спрашивают систему "есть там что для этого дескриптора?" ну и т.д.

Где можно посмотреть пример готового сайта на Express.js?

HoHsi: я честно не видел на гитхабе ни одного приложения, ни на одном языке программирования (если не брать штуки типа postgresql), к коду которого стоит стремиться... все велосипеды, стэш и т.д. Лучшее что есть - отдельные библиотеки из которых строятся фреймворки. В JS мире красивого кода вообще малова-то.

Где можно посмотреть пример готового сайта на Express.js?

HoHsi: посмотрите видяшку и успокойтесь. Там дядя боб рассказывает историю становления архитектуры ПО и аджайлов, как все пошло не так и т.д. Я думаю вам будет полезно.

Где можно посмотреть пример готового сайта на Express.js?

HoHsi: reils like структуру проекта, но не архитектуру. Посмотрите видяшку, а примеры как что с чем готовить и не загоняться есть на гитхабе