copal: для меня MVC это способ снижения связанности и только. То что вы привели - это просто анемичная модель, тупая структура данных. И поскольку вы привели только ее, никакого MVC тут пока не наблюдается.
copal: а вы типичный циник. Вы даже не пытаетесь переварить то что я говорю, вы просто гоните свою точку зрения, которая основана... ну просто на наборе информации. Вы порой выдаете вполне себе интересные мысли, но чаще просто набор бессвязных мыслей.
copal: есть такая проблема у вас, поскольку вы не понимаете что инпут это тоже маленькое MVC приложение и для него модель - это какое-то поле объекта. Переменная по сути.
Все дело в масштабах. В вашем понимании MVC охватывает что-то большое, а в моем весь UI это композиция маленький mvc хреновин, и приложение это вообще отдельно стоит рядом.
vipermagi: ну у вас же будет операция вставки в середину списка например? Со статическим массивом вам нужно будет хэндлить ресайзы и т.д. Интерфейс один, реализация разная.
copal: из вашего описания я так же могу сделать вывод что вы не правильно воспринимаете что такое модель. У вас наблюдается типичное заблуждение что MVC описывает все приложение, хотя это только место соприкосновения приложения и UI. Способ снижения связанности между этими двумя системами (UI и приложение) с целью упрощения поддержки (можно чаще менять UI не затрагивая логику) и увеличения реюзабельности отдельных UI компонентов (гриды например - это полноценное MVC приложение, и их можно реюзать поскольку они никак не привязаны к приложению).
jamaZ то что вы перечислили - это экосистема вокруг, оно не отменяет "ручную работу". С этим тоже надо разбираться и это тоже надо готовить. Тот же сварм автору еще вообще не нужен, так как пока все будет на одной машине. Консул хорошо подходит для разруливания конфигурации и как dns для zero-downtime деплоймента, но руками придется поработать.
1) не нужно их пихать в один контейнер. Они должны быть каждый в своем контейнере. Обращаться они должны по сети. Для удобства рекомендую воспользоваться docker-compose.
2) ридми docker/distribution на гитхабе.
4) ну вот вы в Dockerfile пишите FROM php-fpm например. Вот это и есть базовый образ. Вы можете сделать свой образ и от него уже наследовать остальные, и таким образом вы сможете обновить софт во всех своих образах один раз и потом просто пересобрать остальные.
6) я к тому что зависимости уже должны быть поставлены на момент docker build. У меня для этого просто скрипт для сборки, который перед docker build дергает composer, npm и т.д. У меня даже сборка фронтэнда через gulp/webpack ДО сборки контейнера происходит потому как.... в контейнер уже должно попадать все готовое. Ну а что бы было еще удобнее, можно все эти композеры, npm-ы и т.д. юзать из докера, готовые образы есть и их много.
что до вашей проблемы - вопервых есть там composer под php7 (посмотрите список тэгов). А вопрос с драйверами решается банально --ignore-platform-reqs.
Ну или опять же да, можно сделать как вы предлагаете, но вот честно еще ни разу не сталкивался с проблемами такими, хоть и окружение у меня отнюдь не стандартное.
copal: с SOLID познакомился в 2011-ом году. С GRASP в 2012-ом. MVC "знал" с 2007-ого года, но только годика так 3 назад переосмыслил когда входил в мир фронтэнда где все те же три буквы значили ровно противоположное. На бэкэнде загоняться по MVC смысла не так много с учетом специфики моей работы.
Паттерны не внушают уверенности неопытным программистам. Неопытным программистам должны внушать уверенность тесты, а паттерны дают толчек для проявления эффекта даннинга-крюгера. Я сам когда-то начал сначала зубарить паттерны, и только потом узнал о том что есть еще принципы, из которых все эти паттерны выводятся и которые намного более ясно объясняют почему и для чего применяются те или иные приемы.
Изучение паттернов как правило нарушает причинно следственную связь. Разработчики начинают их пихать просто так, что бы было, ибо это ж круто! А по факту на выходе выходит намного более сложный для суппорта говнокод. И обычно разработчики начинают это понимать только после того как зафэйлился очередной проект.
Я через все эти этапы проходил, и я не хочу что бы разработчики шли этим путем. Есть более продуктивные и безопасные для бизнеса способы обучения.
короткий ответ - для того что бы это понять нужно задаться вопросом "зачем нам нужен MVC/MVA/MVP/MVVM/etc". Ответ - снижение связанности между приложением и UI за счет введение промежуточного объекта. Для удобства это может быть не один объект, а цепочка объектов. Для WEB например UI это HTTP, и нам между HTTP и приложением нужна цепочка адаптеров, которые конвертят взаимодействие пользователя по HTTP к обычному вызову методов нашего приложения (контроллеры - не часть приложения, это прослойка, причем довольно тонкая обычно).
danforth: front controller - точка входа в цепочку контроллеров (адаптеров, мидлвэров, как угодно называйте, читать про Model-View-Adapter). Роутер - компонент, который дергается где-то в цепочке адаптеров, дабы выяснить дальнейшую цепочку.
есть паттерн контроллер, front controller это первый контроллер в цепочке контроллеров (на самом деле адаптеров между http и приложением). В этой же цепочке один из "контроллеров" это роутер.
Денис Инешин: ну это полностью согласен. Я это больше к тому что смысл их делать есть даже если не планируется мобильной платформы. Но что бы выходило выгодно нужно хорошо представлять что делать и на клиенте и на сервере.
как вы думаете, сколько TYNYINT реально занимает места? Что вы скажите по поводу выравнивания размера структур данных? Ну и последнее - сколько нынче стоит мегабайт места на диске?
https://gist.github.com/fesor/e7ccc0467bcb9e6c6a47... - моя статья пока в процессе приготовления. Можете подписаться на изменения и холиваить в комментах.