Не думаю что напишу что-то новое, но менеджмент присутствует всегда, можно выделить одного человека на эту роль, в небольшой команде роль менеджера будет размазана по всей команде.
Но как правило менеджментом в команде разработки ПО обычно занимается опытный разработчик которому близка эта роль(тим.лид).
да, это уже точно будет не MVC, может быть это будет HMVC, а может быть что-то другое, единственное что мне не очень нравиться и это мое личное мнение, что M в MVC часто используют как участок в который можно напихать все от уровня данных до уровня бизнес логики приложения. Лично мое мнение… максимум это должен быть фасад, по этому я и говорю что меня удивляет попытка уложить все приложение в один паттерн(для небольшого приложения оно вполне годится, опять же скорее для desktop или mobile), для веба оно что-то как-то криво выходит)) опять же мое личное мнение
об этом речи и не идет))
фичи в html, css доказательство вашим словам…
Но если бы так многого не желал бизнес от html+css у нас бы до сих пор была бы табличная верстка))
я же до этого как раз и писал что не придерживаюсь паттерна MVC, как минимум мне не нравится абстракция "Контроллер", скорее "Консультант"… попросили, он запросил, он передал в нужном формате…
Я же не спорю о паттернах, скорее говорю что этот паттерн очень хорошо подходит для уровня presentation, ну а роль Контроллера можно передать болеее абстрактно-абстрактному… так сказать менеджментом пусть управляет кто-то другой...
Спорное утверждение, а так да, есть пользователи которые системный блок называют процессором, а браузер интернетом и им не мешает это работать, а другим не все равно.
И интересно… почему вы делите CMS на приложение и сайт.
Если по факту в данном случае это и есть приложение с разделением прав доступа. Одни пользователи могут только видеть контент который другие подготавливают, к тому же, не весь, а который допустим прошел 33 этапа публикации.
да, в самом простом случае.
Но часто выводится не только постоянный контент.
А есть сортировки, фильтрация, формы, система комментариев, поиск…
И это уже по сути приложение, как и со стороны пользователя, так и со стороны администратора сайта.
Не надо забывать что CMS добавляют поболее возможностей окромя того что бы просто накидать страницы, ну если она конечно не написна студентом Васей 2 курса.
это не логика взаимодействия именно с пользователем. Это взаимодействие браузера с веб-сервером.
Логика взаимодействия с пользователем, это когда пользователь просит у веб приложения 2 последние новости отсортированные по названию из категории на которые он подписан.
я писал про статические html, css изображения...., что в свою очередь назвал веб-сайтом.
то что там умеет apache или другой сервер к этим файлам не относится, а относится к настройке веб-сервера.
по поводу Overengineering вопрос спорный и скорее должен рассматривать для конкретных случаев.
Сегодня клиенту нужна просто одна главная страница, а через пару релизов уже новости, статьи. Потом он затих на 3 месяца, а после того как проснулся ему нужна интеграция с CRM и т.д… в какой то мере выбирая сразу фреймворк я беру решения на вырост и не обязан использовать сразу его на 100%, но с другой стороны я не попадаю в ситуацию когда через какое то время мне надо будет писать реализацию с нуля всего и вся.
потому что я не согласен что веб-сайт от веб-приложения отличается....
построен вокруг контента
построено вокруг взаимодействия с пользователем и решения его задач;
Это всего лишь цели приложения.
А если все же делить, то для меня сайт это статические html, css…
делать классификацию "сайт", "Приложение" по целям или по сложности логики или объему… на мой взгляд не верно.
а вот тут я тоже не соглашусь…
для меня веб сайт это когда apache отдает файлы по заданному адрессу, а веб приложение это все что имеет логику и построение ответа на запрос пользователя. И если что то формирует ответ в зависимости от запроса пользователя это уже приложение, а не просто отдает html файл. А имя веб-приложение дано так как оно определяем контекст. Но можно сказать и без контекста, приложение.
Не думаю что напишу что-то новое, но менеджмент присутствует всегда, можно выделить одного человека на эту роль, в небольшой команде роль менеджера будет размазана по всей команде.
Но как правило менеджментом в команде разработки ПО обычно занимается опытный разработчик которому близка эта роль(тим.лид).
да, это уже точно будет не MVC, может быть это будет HMVC, а может быть что-то другое, единственное что мне не очень нравиться и это
мое личное мнение, что M в MVC часто используют как участок в который можно напихать все от уровня данных до уровня бизнес логики приложения.Личномое мнение… максимум это должен быть фасад, по этому я и говорю что меня удивляет попытка уложить все приложение в один паттерн(для небольшого приложения оно вполне годится, опять же скорее для desktop или mobile), для веба оно что-то как-то криво выходит)) опять жемое личное мнениеоб этом речи и не идет))
фичи в html, css доказательство вашим словам…
Но если бы так многого не желал бизнес от html+css у нас бы до сих пор была бы табличная верстка))
на каком уровне приложения?
смешно… Вы действительно думаете что без вложения денег и желания бизнеса появились бы многие технологии… уххх…
Увы требования рождают предложения...
я же до этого как раз и писал что не придерживаюсь паттерна MVC, как минимум мне не нравится абстракция "Контроллер", скорее "Консультант"… попросили, он запросил, он передал в нужном формате…
Я же не спорю о паттернах, скорее говорю что этот паттерн очень хорошо подходит для уровня presentation, ну а роль Контроллера можно передать болеее абстрактно-абстрактному… так сказать менеджментом пусть управляет кто-то другой...
википедия относится к веб 2.0
можете на основе википедии объяснить в чем различие?
Ну вот об этом многие и пишут, а весь сыр бор вроде начался с вашего комментария
вот этому
("то для меня сайт" ключевые слова)
Что тоже не противоричит вроде моему мнению. Так как даже переход по ссылке это запрос пользователя и поведение приложения.
Спорное утверждение, а так да, есть пользователи которые системный блок называют процессором, а браузер интернетом и им не мешает это работать, а другим не все равно.
Ну и значит я пока не замечаю противоречий в своем личном мнении, а все ваши комментарии доказывают это...
И интересно… почему вы делите CMS на приложение и сайт.
Если по факту в данном случае это и есть приложение с разделением прав доступа. Одни пользователи могут только видеть контент который другие подготавливают, к тому же, не весь, а который допустим прошел 33 этапа публикации.
да, в самом простом случае.
Но часто выводится не только постоянный контент.
А есть сортировки, фильтрация, формы, система комментариев, поиск…
И это уже по сути приложение, как и со стороны пользователя, так и со стороны администратора сайта.
Не надо забывать что CMS добавляют поболее возможностей окромя того что бы просто накидать страницы, ну если она конечно не написна студентом Васей 2 курса.
это не логика взаимодействия именно с пользователем. Это взаимодействие браузера с веб-сервером.
Логика взаимодействия с пользователем, это когда пользователь просит у веб приложения 2 последние новости отсортированные по названию из категории на которые он подписан.
я писал про статические html, css изображения...., что в свою очередь назвал веб-сайтом.
то что там умеет apache или другой сервер к этим файлам не относится, а относится к настройке веб-сервера.
по поводу Overengineering вопрос спорный и скорее должен рассматривать для конкретных случаев.
Сегодня клиенту нужна просто одна главная страница, а через пару релизов уже новости, статьи. Потом он затих на 3 месяца, а после того как проснулся ему нужна интеграция с CRM и т.д… в какой то мере выбирая сразу фреймворк я беру решения на вырост и не обязан использовать сразу его на 100%, но с другой стороны я не попадаю в ситуацию когда через какое то время мне надо будет писать реализацию с нуля всего и вся.
потому что я не согласен что веб-сайт от веб-приложения отличается....
Это всего лишь цели приложения.
А если все же делить, то для меня сайт это статические html, css…
делать классификацию "сайт", "Приложение" по целям или по сложности логики или объему… на мой взгляд не верно.
Хм… не точно написал…
Для меня сайт это статические html файлы, тоесть его можно и локально смотреть, не каких других вещей он не требует.
Все что имеет хотя бы минимальную логику уже является веб приложением, или вернее требует для своей работы не только сервер что-бы отдавать файлы.
Да, если мы берем статусы ответов.
Но на формирования контента он не как не влияет, для этого нужны другие инструменты.
А почему бы мне не использовть MVC фрейморк для приложения аля "Hello world"?
а вот тут я тоже не соглашусь…
для меня веб сайт это когда apache отдает файлы по заданному адрессу, а веб приложение это все что имеет логику и построение ответа на запрос пользователя. И если что то формирует ответ в зависимости от запроса пользователя это уже приложение, а не просто отдает html файл. А имя веб-приложение дано так как оно определяем контекст. Но можно сказать и без контекста, приложение.