Вхід і реєстрація
×
Розробка · 24 грудня 2010, 16:27 861
Inoketiy Mogilyov

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

Підписуйтеся на Telegram-канал «DOU #tech», щоб не пропустити нові технічні статті

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

Знаком с подходом реализации с сервислаерами где и хранится вся бизнес логика, но даже так все заганяется в рамки и ты реально не разбиваешь домен на классы не строиш их иерархий с применением шаблонов проектирования, а тупо всё вигачишь в соответствующие сервислаеры. При таком подходе идет большая связанность с непосредственно слоем работы с БД. А еще больше вопросов возникает при построении модульных приложений и наследовании модулей. Пишу с позиции использования 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
Александр Маненко 27.12.2010 18:43

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

ы?

Відповісти
Підтримати
anonymous 27.12.2010 18:15

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

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

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

Відповісти
Підтримати
св Антоний 25.12.2010 19:01

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

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

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

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

Відповісти
Підтримати
Александр Маненко 25.12.2010 13:46

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

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

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

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

Відповісти
Підтримати
Inoketiy Mogilyov 25.12.2010 12:07

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

Відповісти
Підтримати
Inoketiy Mogilyov 25.12.2010 12:01

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

Відповісти
Підтримати
anonymous 25.12.2010 11:30

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

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

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

Відповісти
Підтримати
anonymous 24.12.2010 23:30

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

Відповісти
Підтримати
Yura Peskov Engineering Manager 24.12.2010 22:47

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

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

Відповісти
Підтримати
proger 24.12.2010 20:46
не знаю откуда там оргазм, студенты на третьем курсе пишут свои фреймоврки на c++ с аналогичным функционалом.

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

Відповісти
Підтримати
св Антоний 24.12.2010 20:27

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

Відповісти
Підтримати
proger 24.12.2010 20:21
n0xYIcT. +1
хотя, лично я предпочитаю контроллер делать с самой-самой верхнеуровневой логикой, перенося всю имплементацию в модели.,

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

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

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

Відповісти
Підтримати

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

Не підписуватись
Скористайтесь акаунтом
×
з умовами використання сайту і політикою конфіденційності.