LINUX.ORG.RU

Вы тоже во всех проектах используете паттерн MVC ? php

 ,


0

1

Существуют же способы отделить логику от шаблона. К примеру создать класс (условно Application) в нем определять роуты(в конструкторе, например: /?url=getInfo) и вызывать методы в этом классе(метод = getInfo в данном случае) которые выполнят подключение к БД, бизнес-логику и отдадут это все в шаблон (другой php файл).


Ответ на: комментарий от Zhbert

Он, вероятно, хочет сказать, что не всегда нужно выделять три уровня, где-то достаточно двух. Ну или я не понял.

hobbit ★★★★★
()

отвечаю на заголовок:

нет, не везде и не всегда, ибо мвц это один из паттернов

deep-purple ★★★★★
()

Так это и будет MVC. Просто в качестве модели у тебя СУБД.

no-such-file ★★★★★
()

MVC всего лишь один из подходов. Способов разных всяких много. Мы обычно используем либо mvc, либо компоненты+сервисы, то есть когда приложение состоит из клиентских компонентов, серверных компонентов и сервисов для связи всего воедино.

В общем пишите так, как вам удобно, главное не забывать писать так, чтобы потом это можно было как-то поддерживать:)

ixrws ★★★
()
Ответ на: комментарий от crutch_master

И чем он не вписывается в MVC? Обычно весь фронт можно рассматривать как view для серверной части. А внутри фронт также может быть MVC, если по современному наворачивать.

MVC вообще пофиг на чём его реализуют, просто веб разработчики часто забывают(или вовсе не знают) про то, что MVC появился задолго до этой самой веб разработки и вообще не про то оно.

ixrws ★★★
()

и отдадут это все в шаблон (другой php файл).

Так то ты можешь делать шаблон на фронтенде (реакт к примеру), а php будет в качестве API (rest к примеру)

abs ★★★
()
Ответ на: комментарий от ixrws

В общем пишите так, как вам удобно, главное не забывать писать так, чтобы потом это можно было как-то поддерживать:)

Пока ты будешь писать так, чтобы можно было поддерживать, конкурент наймёт команду макак, которые наговнокодят кое-как, продаст это, и запилит вторую и третью версии.

beaver
()

уходил 2019 год..

anonymous
()
Ответ на: комментарий от beaver

Слышал такое мнение не раз, в том числе и от начальства. Однако маками обычно не справляются с поддержкой. Они и разработчики как одноразовые салфетки и команды из-за них одноразовые и продукты тоже получаются одноразовые. Всё бы не беда, если бы не одноразовые продукты. Скажем вам заказывают тот же интернет магазин, его кое-как запилили макаки. Но потом он начинает работать и оказывается, что он не готов и ещё и всё разваливается то тут то там. Поправить это макаки не могут, от слова совсем. Никакие тесты не решают проблем, их же опять же пишут макаки. Вторая и третья версия будет в лучшем случае такого же качества как первая, а обычно ещё хуже, потому что их будут пилить другие команды макак и стараться чисто визуально чтобы продукт походил на старый. Заказчик будет постоянно исходится на говно, что он вам уже объяснял какие-то мелочи 2а года назад, а вы 10 раз эти мелочи ломаете и даже не способны записать хотелки в список.

В итоге заказчик пройдя через весь этот ад находит более-менее адекватных исполнителей и его продукт они поддерживают пожизненно.

И да, писать проект так чтобы его можно было поддерживать не сложно. Не надо никакого сильно мудрёного проектирования и расчётов заранее. Достаточно элементарного планирования на средний срок. Да, этого не умеют и не хотят уметь сегодня большинство. Но и раньше так было. Просто раньше никто не ставил слесаря инженером, это были разные специальности.

ixrws ★★★
()
Ответ на: комментарий от ixrws

И чем он не вписывается в MVC?

А внутри фронт также может быть MVC, если по современному наворачивать.

Ну, вот всем этим он и не вписывается. Классический mvc проще, а тут на сервере api, который тоже может быть типа mvc, на клиенте spa, в внутри которого mvc и т.д. Обычно MVC - это чисто server-side обработчики запросов, шаблоны и модели в виде какой-нибудь фигни из классов и orm.

crutch_master ★★★★★
()
Последнее исправление: crutch_master (всего исправлений: 1)
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.