|
|
 2 Мб |
|
|
для: Sfinks
(16.03.2012 в 20:37)
| | Наглядный вариант реализации MVC в файле
Есть IDE, которые работают с MVC. Так или не так? | |
|
|
|
|
|
|
|
для: cheops
(29.03.2012 в 16:52)
| | Я просто хотел подсказать и не навязываюсь.
Провел аналогию. Не строгую аналогию, как отображение элементов признаков.
А нет, получилась строгая аналогия. | |
|
|
|
|
|
|
|
для: roma67
(28.03.2012 в 15:01)
| | >>так я ж уже отказался от MVC
>Извините? Я выборочно предыдущие прочитал, но последнее меня затронуло.Допустим Объект-
>представление (Модель - Вид)
>Объект - таблица базы, например пользователи, товары
>Представление - Разные страницы для одной таблицы. Например при регистрации,
>авторизации, формировании списков пользователей, формировании карточки пользователя.
Куда контроллер то потеряли? Где он у вас?
>Истина где-то посередине, но она вокруг да около ходит
Конечно, но ракету с кучей параллельных двигателей, не обязательно всегда называть мотодвительным движетелем... речь ровно об этом, что не нужно весь ООП называть MVC - это не так, MVC часть ООП, а не наоборот. | |
|
|
|
|
|
|
|
для: Sfinks
(19.03.2012 в 17:35)
| | >так я ж уже отказался от MVC
Извините? Я выборочно предыдущие прочитал, но последнее меня затронуло.Допустим Объект- представление (Модель - Вид)
Объект - таблица базы, например пользователи, товары
Представление - Разные страницы для одной таблицы. Например при регистрации, авторизации, формировании списков пользователей, формировании карточки пользователя.
Важно, на мой взгляд , что если вы неудачно определите поля таблицы, то вам менять каждый раз при доработке.Второе, если у вас код php перемешан с html , дорабатывать на определенном этапе развития станет проблемой.
Еще момент. Все можно засунуть в один файл. Первое что исторически отделяют - данные.Если вам удобно развивать все в одном файле, то мир прекрасен. Дальше одним удобнее процедурное, другим классы, но всегда одно важно, как вам лично быстрее дорабатывать. Пока вы не попробуете сами, вы сами не узнаете. А не попробуете, пока не будете чувствовать проблемы при доработках и изменениях под разные задачи. Так, для наглядного примера, в фильме Укрощение огня показано, что монолитный проект ракеты , без ступеней, не жизнеспособен для будущего. Потом оказалась, что последовательная схема ступеней у ракеты хуже параллельной. Я привел пример, что в процессе вашего развития личные взгляды могут меняться и любой человек начинает ходить кругами в поисках оптимального способа.Истина где-то посередине, но она вокруг да около ходит | |
|
|
|
|
|
|
|
для: cheops
(19.03.2012 в 16:17)
| | так я ж уже отказался от MVC ) Ладно, в этой теме уже путаница что к чему относится. Будут еще вопросы, буду новую тему заводить. Еще раз спасибо! | |
|
|
|
|
|
|
|
для: Sfinks
(19.03.2012 в 10:40)
| | >> Нет-нет... элемент меню, это ни разу не класс...
>Почему не класс? А с точки зрения администратора ресурса?
С точки зрения MVC.
>Т.е. у него должны быть методы: Добавить, удалить, переместить, скрыть и т.п.... Или админ-
>часть тоже в отдельный класс выносить принято?
Может, но уже на другом уровне, не на уровне MVC. Т.е. при реализации представления View, можно уже заводить какое угодно количество классов, четко выполняя интерфейсный ограничения MVC, т.е. не лазя, например, за элементами меню в базу данных напрямую. | |
|
|
|
|
|
|
|
для: cheops
(17.03.2012 в 12:02)
| | Чем дальше в лес.....
> Нет-нет... элемент меню, это ни разу не класс...
Почему не класс? А с точки зрения администратора ресурса? Т.е. у него должны быть методы: Добавить, удалить, переместить, скрыть и т.п.... Или админ-часть тоже в отдельный класс выносить принято? | |
|
|
|
|
|
|
|
для: Sfinks
(18.03.2012 в 21:09)
| | Да первом же сообщении отговаривать принялся :))), ну может не совсем четко, но не хотелось вообще напропалую критиковать, все-таки уважаемый паттерн, многими любим :)))
>Я вообще не считаю эту модель удачной именно для Web | |
|
|
|
|
|
|
|
для: cheops
(18.03.2012 в 12:11)
| | Тыдышшщь!!! )))
А зачем же вы так долго объясняли, как важно все поделить и разграничить? ) Так и написали бы.... мол пиши как получится, особо не заморачивайся, помни что не стоит смешивать разные функции разных модулей. А на следующем проекте поймешь где что недоучел (все учесть все равно не получится)
)))
Так и буду делать ) Спасибо )) | |
|
|
|
|
|
|
|
для: Sfinks
(17.03.2012 в 22:26)
| | Э... именно MVC? Не думаю, что есть чистый, мы считаем, что этот паттерн не очень выгоден в Web, лучше говорить о разделении HTML и PHP, текста и HTML, компонентах, чем о MVC. MVC - это проблема построения монолитного приложения, а сайты очень редко бывают монолитными (ну разве что какой-нибудь сайт с крутыми личными кабинетами на которые все увязано). Большинство же сайтов модульные - гораздо важнее вводить модули и убирать их. Я вообще не понимаю зачем вам именно MVC? Почему бы просто не построить удобную вам ООП-модель? Тот же VCL в Delphi - он же ни разу не MVC, они тоже контроллер схлопнули, рассовав его по моделям и представлению, из-за чего стало очень удобно делать утилиты, в которых документ и его множественное представление вообще не нужны. У сайта очень редко бывает множественное представление одной и той же информации, а когда бывает проще эту проблему решать через шаблоны - так как верстка зубодробительная: если растаскать HTML-верстку по классам, вы потом костей не соберете, важно чтобы верстка сосредотачивалась в едином файле. Я вообще не понимаю, почему все с MVC так носятся, да очень известный паттерн, но он же не единственный, да и в Web без него проблем полно, которые MVC не решает, а просто отвлекает ваше внимание от них. Более того, и Web, и PHP долгое время развивались без ООП, проблемы, которые решает MVC решали другими средствами тоже вполне себе элегантными - вводом новых языков программирования (да еще декларативных!). Декларативные языки + ООП: гремучая смесь, они решают одни и те же задачи разными способами, очень сильно можно влететь запутав их на уровне архитектуры. | |
|
|
| |
|