Правильное построение модели в MVC

Вот часто вижу такие что вообще бизнес логику в контроллерах пишут, но это не правильно.

Знаком с подходом реализации с сервислаерами где и хранится вся бизнес логика, но даже так все заганяется в рамки и ты реально не разбиваешь домен на классы не строиш их иерархий с применением шаблонов проектирования, а тупо всё вигачишь в соответствующие сервислаеры. При таком подходе идет большая связанность с непосредственно слоем работы с БД. А еще больше вопросов возникает при построении модульных приложений и наследовании модулей. Пишу с позиции использования ZF и Doctrine 1.4

Знаю что в Doctrine 2 много изменений и возможно они решают эти проблемы

👍НравитсяПонравилось0
В избранноеВ избранном0
LinkedIn
Допустимые теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter
Допустимые теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter

Любители Lunix качают свой терминал, конечно по такой схеме легко будет, перейдите на Mac, и там запоёте.

ы?

Дети, вспомните где разработана MVC- в SmallTalk-80 она была изобретена для отделения пользовательского интерфейса от основных данных приложения. Для детских проектов конечно можно и не думать о MVC, но в разработке крупных проектов в масштабе корпоративного предприятия вы помучаетесь если будете впихивать код GUI вместе с бизнес — логикой программы, путаница и код маячить -GUI будет как мельтищняк, поверьте я не один год работаю в C++/Java. Любители Lunix качают свой терминал, конечно по такой схеме легко будет, перейдите на Mac, и там запоёте.

2 Денис Леухин
Сначала немного поругаюсь.
Чтение программистских книжек на английском языке приводит к совершенно неправильному пониманию их смысла. Например, слово «бизнеспроцессы» или «бизнесправила» никакого отношения не имеет к MVC. В этих книжках оно используется в качестве примера. Русскому человеку понятней на бутылках.
Теперь о деле. Одного MVC мало. Для представления (презентации) данных вы каждый мандаринчик заворачиваете в фирменную упаковку для привлечения диких обезъян на Ваш сайт. Но дедушки, которые на нашу голову придумали протокол HTTP, предусмотрели, что бы без малейшего желания обезьяны ничего на экране не происходило, даже если нет давно связи с сервером. Поэтому без скриптов у клиента никакого web2.0 не получится. Теперь о REST. Эта штука просто задаёт стандарт интерфейса между представлением (страничкой и куками) у клиента и контроллером на сервере. Контроллер должен уметь как минимум следующие вещи:
1) показать содержимое портфеля (сгенерить страничку или данные для странички со списком);
2) положить новый предмет в портфель (например бутылку), т.е. форму по добавлению нового предмета;
3) вынуть предмет из портфеля (удалить бутылку и выпить);
4) изменить предмет в портфеле (надкусить бутерброд или намазать кетчупом), т.е. форму по исправлению предмета;
Когда Вы эти 4 вещи написали, у Вас есть магазин, блог, developers.org.ua и прочий сайт. Остальное — рюшечки.

Пагинаторы, авторизация, бизнесправила, кеширование и т.и д. — всё должно делаться по REST.


что бы бизнесс логика была строго не привязана к данным, а просто использовала их

Внутри контроллера все будет строго и типизировано. Дело в том, что контроллер в данном случае будет конкретным (имею ввиду как абстрактный класс А — конкретный класс А). В противном случае, если ты хочешь в контроллере сохранить какую-то абстракцию — это может повлечь ухудшение производительности

2dev.demi:
В шаблоне MVC, насколько я помню, инкапсулированы модель и представление, а также ассоциированный с ними контроллер, который является видимым. Модель инкапсулирована полностью — не видна. Ее назначение — низкоуровневый доступ к данным. Представление — иногда смотрит во внешний мир, иногда доступно только через контроллер. Его назначение — представление данных (с которыми оперирует модель). Контроллер нужен для связи MVC с внешним миром, + по возможности инкапсуляция бизнес-процесов, для повышения уровня абстракции. Это теория.

На практике — или сделать базовый контроллер, а в нем переопределяешь виртуальные методы. Или всю логику вынести в отдельный класс просто. Только по-хорошему нужно написать общий интерфейс для них. Я б так сделал.


Страуструп писал про ООП: «Если Вы не можете выразить свою мысль в объектах, Вам уже ничего не поможет».

Если Вы можете выразить свою мысль только в объектах, Вам уже ничего не поможет.

> Страуструп писал про ООП: «Если Вы не можете выразить свою мысль в объектах, Вам уже ничего не поможет».

ООП все проблемы не решает, есть много задач которые выходят за рамки ООП.

если следовать тупо мвц, то просто кодим систему и нифига ее не проектируем, так как у нас есть модели — проекции таблиц, а иногда это не отображает реальных объектов системы и вот почему у меня появился данный вопрос о правильном построении модели

n0xYIcT, хорошо поставил я всю бизнес логику в контроллер, ладно даже вынес в приватный метод, но тут мне бац нужен новый модуль который должен использовать эту логику и как к ней дотянуться, скопипастить, конечно контроллер полностью лишить логики невозможно, но она должна отвечать только за то куда отправить запрос от пользователя. Вот даже тот же вебформс в асп.нет понятней есть BAL и DAL, есть иерархия классов допустим тот же портфель у него есть разные строители или разные стратегии и они получают данные с DAL, а в мвц понятие модель очень широкое оно означает по сути домен и как ее правильно реализовать загвоздка, что бы бизнесс логика была строго не привязана к данным, а просто использовала их.

MadProfessor, спасибо за ссылки.
Андрей, благодарю за пояснение на простом примере, более менее понятно.

2 Денис Леухин MVC мало, учи ещё и REST.
Страуструп писал про ООП: «Если Вы не можете выразить свою мысль в объектах, Вам уже ничего не поможет».
Только одна тонкость. Есть устойчивые объекты и неустойчивые. Вроде портфель (список) устойчивый объект. Но в него можно положить 10 бутылок водки, а можно 9 и два сникерса. Вот Вы написали функцию, которая хорошо работает с 10 бутылками, но во втором случае выдаёт «Access еrror...» Дальше есть три варианта
1) писать функции «на все случаи жизни» наполнения портфеля;
2) плодить типы объектов «Портфель10», «Порфель9и2сникерса» и т.д. и дальше плодить виртуальные функции по организации пьянки;
3) создать объекты «бутылка» и «бутерброд», имеющие функции «выпить» и «сожрать», ,
а в функции портфеля «пьянка» вызывать оные при обработке списка в большом кейсе. Если попадётся ручка, её есть ненадо.

Естественно третий вариант более похож на этот мир. Соответственно, меньше ошибок, и всё это просится в контроллер. Проверкой на съедобность должна заниматься Модель. Кроме того в портфель непомещается гранатомёт, придётся в руках нести.

Кто может дать ссылки на статьи или вообще материал, в котором доходчиво объясняется про MVC?

Вот часто вижу такие что вообще бизнес логику в контроллерах пишут, но это не правильно.

особенно нравится фраза «но это не правильно». Реальная жизнь и задачи намного многограннее. И часто стоишь перед выбором либо передавать куеву тучу параметров в модель, или решить приватным методом на месте в контроллере.

не знаю откуда там оргазм, студенты на третьем курсе пишут свои фреймоврки на c++ с аналогичным функционалом.

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

2proger: ADO.net entity framework + LINQ = более мощное орудие + доставит душевный оргазм

n0xYIcT. +1
хотя, лично я предпочитаю контроллер делать с самой-самой верхнеуровневой логикой, перенося всю имплементацию в модели.,

а там как получится... удобней всего идти за проектом, а не пытаться заставить проект подчиниться моим предпочтениям

Блаблабла... блаблабла... блаблабла... Учим мат. часть, что есть Model, что есть View, а что есть Controller
Контроллер он вообще, не побоюсь этого слова, ассоциирован, и с моделью, и с представлением, так что каждый точит как он хочет.

Пля, модель-низкоуровневый доступ, представление — представление, контроллер — бизнес-логика. Контроллер выполняет роль посредника, так что все зависит от абстракции.

Подписаться на комментарии