Comments 51
ну если вы говорите об MVC как об отдельных частях системы, то это в принципе невозможно. Хоть где то части теории должны соединяться и иметь какую то связь (coupling). Надо просто стремиться к минимальной связности (сопряженности если верить перевод Совершенного Кода Макконнела, в общем loose coupling на англ) между обьектами и тогда все будет прекрасно.
Вы говорите о сотнях и тысячах строк копипаста. Так простите это уже дублирование кода и следовательно ужаснейшая архитектура. MVC не имеет никакого отношения к способности создавать архитектуру проекта.
Вы говорите о сотнях и тысячах строк копипаста. Так простите это уже дублирование кода и следовательно ужаснейшая архитектура. MVC не имеет никакого отношения к способности создавать архитектуру проекта.
интересная тема…
а, б) как можно утверждать невозможность сделать что-либо по каноническому описанию если канонического описания не существует?
в) МВЦ не есть программой которую нужно реализовать а паттерном или набором договоренностей которым нужно следовать. платформа имплементирующая МВЦ паттерн совсем не обязательно должна использовать этот паттерн.
г) обьяснений нет; д, е) не видел не значит не существует или невозможно.
вот вы говорите «Не надо впихивать нивпихуемое. Незачем пыжиться и повсюду совать паттерны и объекты.» а потом сразу «нужно всего лишь выбрать правильную среду разработки и подумать об архитектуре, расширяемости и поддержке проекта»
а ведь эти самые паттерны и есть в частности результатом размышлений об архитектуре, расширяемости и поддержки кода.
а, б) как можно утверждать невозможность сделать что-либо по каноническому описанию если канонического описания не существует?
в) МВЦ не есть программой которую нужно реализовать а паттерном или набором договоренностей которым нужно следовать. платформа имплементирующая МВЦ паттерн совсем не обязательно должна использовать этот паттерн.
г) обьяснений нет; д, е) не видел не значит не существует или невозможно.
вот вы говорите «Не надо впихивать нивпихуемое. Незачем пыжиться и повсюду совать паттерны и объекты.» а потом сразу «нужно всего лишь выбрать правильную среду разработки и подумать об архитектуре, расширяемости и поддержке проекта»
а ведь эти самые паттерны и есть в частности результатом размышлений об архитектуре, расширяемости и поддержки кода.
MVC хорошо живет там, где есть делегаты и замыкания. Попытки его применить в C++, Java (замыкания есть, делегатов совсем-совсем нету) и php (а в php есть делегаты?) на моей практике печальны.
Зато если к C++прикрутить делегаты ( Qt ) то получается неплохо. местами :).
Зато если к C++прикрутить делегаты ( Qt ) то получается неплохо. местами :).
А можно подробнее о том, как связна реализация МВЦ м делегированием и замыканиями?
В j2ee проблемы с реализацией MVC? o_O
В j2ee проблемы с реализацией MVC? o_O
А можно подробнее о том, как связна реализация МВЦ м делегированием и замыканиями?
M, V и C надо связывать между собой. Связь только замыканиями как в java приводит к очень большому объему кода на каждую связь и отсутствию loose coupling. Связь делегатами позволяет делать EditWndView.OnOk.Connect( EditModel.OnEditOk ), части становятся не связанными и легко меняемыми.
Но это все по большей части из личного опыта, а он больше в С и C++ :).
В Java нет как таковых замыканий, только анонимные классы, но это немного не то.
Но есть же Reflection и аннотации.
Кроме того можно передавать непосредственно классы (используя интерфейсы).
Но есть же Reflection и аннотации.
Кроме того можно передавать непосредственно классы (используя интерфейсы).
Интерфейсы требуют кода. При использовании интерфейсов для связи между собой M, V и C проект даже от сотни тысячь строк превращается в много-много копипаста или автогенеренного кода. Что плозо сказывается на поддержке и сопровождении.
Рефлекшн с аннотациями это да, но тогда это уже и не совсем джава получается? :) Так же как Qt — не совсем C++
Рефлекшн с аннотациями это да, но тогда это уже и не совсем джава получается? :) Так же как Qt — не совсем C++
Рефлекшн с аннотациями это да, но тогда это уже и не совсем джава получается? :)Эммм, почему? ) Это же часть стандарта…
Возможно делегирование и проще в плане кода, однако, мне кажется, что интерфейсы «понятнее». Глядя на класс мы сразу видим его функциональность, в отличии от делегирования.
Ладно, это уже оффтоп =) Думаю не стоит раздувать тут обсуждение этого.
поясните о «делегатах»? пруфлинки для любых языков
мне интересно
мне интересно
Абсолютна не понятна позиция автора, и вывод в конце статьи не помогает.
Код, который приведен в конце, — это вообще что?
Код, который приведен в конце, — это вообще что?
код, который приведён в конце — это стёб о позиции «всё есть объект», в частности для пхп
вы невнимательно читали
вы невнимательно читали
Я проситал даже не 1 раз, однако, не увидел юмора.
Фраза автора значила примерно следующее
«код пишется только в рамках ООП и только в рамках МВЦ»
То что МВЦ асбтрактная вещь (не имеющая канонической реализации) — это понятно, но идея довольна конкретная.
я, например, пишу весь код в рамках ООП, у меня нет кода вне классов вообще (не считая шаблонов вью). Это плохо?
ЗЫ в чисто ООПшных языках «все есть объект» в прямом смысле.
Фраза автора значила примерно следующее
«код пишется только в рамках ООП и только в рамках МВЦ»
То что МВЦ асбтрактная вещь (не имеющая канонической реализации) — это понятно, но идея довольна конкретная.
я, например, пишу весь код в рамках ООП, у меня нет кода вне классов вообще (не считая шаблонов вью). Это плохо?
ЗЫ в чисто ООПшных языках «все есть объект» в прямом смысле.
Правильно ли я вас понял?, что к примеру, такой «хелловорлд»:
echo «hello world»;
лучше чем такой:
www.phppatterns.com/docs/design/hello_world_in_patterns
echo «hello world»;
лучше чем такой:
www.phppatterns.com/docs/design/hello_world_in_patterns
UFO just landed and posted this here
МВЦ так и не имеет канонического описания.
&&
классический МВЦ утверждает независимость трёх компонентов
парадокс!
UFO just landed and posted this here
Ошибка в том, что не правильно понимают, что такое контроллер. Отсюда и все ошибки проектирования.
Да, MVC не таки нужен. Hail FRP!
MVC никогда и не был ни технологией, ни шаблоном проектирования. Это всего лишь парадигма.
Иногда очевидно, что интерфейс должен выглядеть определённым образом, а база данных уже сформирована.
В этом случае без дополнительных взаимодействий Контроллера и Модели уже не обойтись.
Но это, как мне кажется, начинает противоречить MVC от GoF и прочим религиям.
Я придерживаюсь такого, что:
— «Вид» отвечает за вывод
— «Модель» работает с логикой над данными
— «Контроллер» что только не делает, чтобы связать «Вид» и «Модель».
Контроллер, я считаю, должен предоставлять модели безопасные данные. (фильтрация)
А модель уже решает что делать с ними и правильны ли они с точки зрения приложения.
При этом я помню про то, что толстый контроллер — это моветон.
php, ZF
В этом случае без дополнительных взаимодействий Контроллера и Модели уже не обойтись.
Но это, как мне кажется, начинает противоречить MVC от GoF и прочим религиям.
Я придерживаюсь такого, что:
— «Вид» отвечает за вывод
— «Модель» работает с логикой над данными
— «Контроллер» что только не делает, чтобы связать «Вид» и «Модель».
Контроллер, я считаю, должен предоставлять модели безопасные данные. (фильтрация)
А модель уже решает что делать с ними и правильны ли они с точки зрения приложения.
При этом я помню про то, что толстый контроллер — это моветон.
php, ZF
на мой скромный взгляд, не стоит канонизировать какие-либо паттерны(тем более архитектурные). все применимо в определенной ситуации.
автор пишет о приверженцах MVC как о сферических фанатиках в вакууме, которые пихают его куда только можно. таких, по моему, не стоит считать.
автор пишет о приверженцах MVC как о сферических фанатиках в вакууме, которые пихают его куда только можно. таких, по моему, не стоит считать.
Мне кажется что вы зря добавили «злое дополнение».
То что среди пхп-программистов много людей пишущих плохой код и так известно.
Вы там привели пример «якобы МВЦ». Ну это понятно — мы таких примеров тоже насмотрелись.
Хотелось бы все таки услышать какие — нибудь аргументы против «известных» реализаций. Например хотя бы того же Zend Framework.
Или DJango (хотя там и не MVC, а MTV o_O)
То что среди пхп-программистов много людей пишущих плохой код и так известно.
Вы там привели пример «якобы МВЦ». Ну это понятно — мы таких примеров тоже насмотрелись.
Хотелось бы все таки услышать какие — нибудь аргументы против «известных» реализаций. Например хотя бы того же Zend Framework.
Или DJango (хотя там и не MVC, а MTV o_O)
вероятно, вы никогда не были на phppatterns
две самые известные схемы: а) «контроллер» определяет «модель» и «вид» и передаёт между ними данные б) «контроллер» определяет «модель», «модель» определяет «вид» — не являются мвц
зы: вообще-то, я хотел оставить интригу для читателя ;)
две самые известные схемы: а) «контроллер» определяет «модель» и «вид» и передаёт между ними данные б) «контроллер» определяет «модель», «модель» определяет «вид» — не являются мвц
зы: вообще-то, я хотел оставить интригу для читателя ;)
И да, не был :)
Но вот у меня складывается впечатление что вы судите об MVC глядя на примеры его реализации выложенные на phppatterns.
И сами же говорите что эти примеры «не MVC».
Я например то что вы назвали «схемой» даже паттерном назвать не могу.
Вы критикуете наколеночные реализации. Но они же никому не нужны. Вася Пупкин написал кривую реализацию MVC => MVC — не существует.
И да, я снова реквестирую критику реализации MVC в ZF :)
Но вот у меня складывается впечатление что вы судите об MVC глядя на примеры его реализации выложенные на phppatterns.
И сами же говорите что эти примеры «не MVC».
Я например то что вы назвали «схемой» даже паттерном назвать не могу.
Вы критикуете наколеночные реализации. Но они же никому не нужны. Вася Пупкин написал кривую реализацию MVC => MVC — не существует.
И да, я снова реквестирую критику реализации MVC в ZF :)
Вспомнилась мне почему — то фотка из инета, где бабка стоит с табличкой «Вы все больные и не лечитесь, а я одна умная, красивая в белом платье стою.»
Огромное количество людей используют MVC и считают это удобным. Вы, я так понимаю, используете его в том числе. Так в чем же собственно проблема?
Огромное количество людей используют MVC и считают это удобным. Вы, я так понимаю, используете его в том числе. Так в чем же собственно проблема?
Sign up to leave a comment.
MVC не существует