логика приложения

[wordwild]

постоянно встречаю посты, о том что логику приложения нужно сОвать в модель.
кто-то может объяснить, что логика забыла в моделе и почему нужно ее туда совать?

[panandy]

Популярные фреймворки работают по принципу MVC (Model-View-Controller). В котором:
Model - отвечает за работу с данными, их организация (базы данных, файлы и другая логика)
View - представление, вид нашего приложение. В основном это просто шаблоны
Controller - Связующее звено между ними. Он оперирует данными, получеными из модели подключая их в представление.
Это означает, что в контроллере нельзя подключатся к базе, нельзя оперировать с файлами и т.д.

Модели бывают разные. Можно использовать ORM системы,А можно делать обертки вокруг обычных команд.
Например class User, method FindById(int id)
Класс User, функция FindById - ищет юзера по ид.
А в контроллере $result = $user->FindById($user_id);

А вообще погугли на тему MVC.
http://ru.wikipedia.org/wiki/Model-View-Controller
http://www.chtivo.webhost.ru/articles/mvc.php

[wordwild]

Controller - Связующее звено между ними. Он оперирует данными, получеными из модели подключая их в представление.

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

P.S. и гуглил, и читал "шаблоны проектирования", и несколько раз на разных php-форумах обсуждал... но конкретного ответа никто не дал.

[Big_Shark]

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

[wordwild]

Книга Design Patterns: Elements of Reusable Object-Oriented Software, глава 1... Читаем:

The View-Controller relationship is an example of the Strategy (349) design pattern.
A Strategy is an object that represents an algorithm. It's useful when you want
to replace the algorithm either statically or dynamically, when you have a lot
of variants of the algorithm, or when the algorithm has complex data structures
that you want to encapsulate.

Пишут что логика (алгоритм) в модели не лежит. Что логика в контроллере, который как сказал panandy "оперирует данными", а значит реализует алгоритм.
Загадка, блин... Просветите.

[БОШ]

постоянно встречаю посты, о том что логику приложения нужно сОвать в модель.

Что авторы этих постов вкладывают в слово "логика" ?
И кто сказал, что алгоритм должен лежать в модели?

[wordwild]

Я не знаю, что вкладывают авторы постов (в частности Big_Shark), но я, для определения термина "логика", руководствуюсь википедией. где сказано:
1. Логика - наука (это пропускаем).
2. Цитата:

Слово «логика» используется также в значениях «внутренняя закономерность, присущая тем или иным явлениям» или «правильный, разумный ход рассуждений».

3. А также:

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

Таким образом в контроллере реализуется "логика событий" (по-моему мнению), то есть описываются действия и реакции на будущие события - те события, которые будут происходить с приложением, в процессе его эксплуатации.

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

[kosenka]

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

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

[mc-bear]

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

Вопрос стоит как правильно делать а не как удобно тебе. С такими рассуждениями как у тебя, тогда сдались тебе эти стандарты MVC, делай как тебе удобно.

PS/ Мне вот тоже ближе мнение что в моделях опереруют данными, логика должна быть в контроллерах.

[wordwild]

ближе мнение

Вот-вот, а хочется узнать Истину... )))
Просто поддержка приложений (до CI-шных) отнимает много времени по причине не всегда удачного проектирования. Понятно, что каждое новое приложение частично избавлено от недостатков предыдущего, но с CI я таким шатанием заниматься не хочу. Сейчас работаю над двумя проектами, в той стадии, что еще можно остановиться и кое-что переписать. Перечитывал форум, наткнулся на это - topic177.html#p1169 поэтому эту тему решил поднять... Сам разберусь, да и другим полезно будет, думаю...

[kosenka]

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

Вопрос стоит как правильно делать а не как удобно тебе. С такими рассуждениями как у тебя, тогда сдались тебе эти стандарты MVC, делай как тебе удобно.

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

[iniweb]

Для меня модель это только работа с БД, контроллер это связующий компонент между библиотекой и моделью (Тоесть к примеру функция pagination я не положу в контроллер никада, только для класса бэкенда), библиотека это то где описываеться впринципе вся логика скрипта обработка парсинг и тд.

[wordwild]

данные глупые

Не знаю этого термина. Расскажите что под этой фразой подразумевается.

[taral]

Меня тоже заинтересовала эта тема. Что мне не понравилось в вашем обсуждении что часто переходят на личные выяснения отношений.
Мне кажется что мы все тут собрались что-бы понять как лучше писать и структурировать код.
Поскольку четкого решения я не увидел. Что нужно четко делать так а не иначе.
Предлагаю поступить так.
Кто хочет более подробно распишет как он структурирует код. Что у него в модели, что в контроллере.
Возможно так мы сможем лучше понять как правильнее писать.
Начну я.
В первую очередь. В файле контроллеров я создаю пару глобальных переменных.
Для title страници, для стилей что нужно загрузить для этого контроллера, скриптов и для глобальных переменных javaScript.
В контроллере я проверяю на валидность данные, получаю записываю данные в сессию, загружаю библиотеки, хелперы, языковые файлы, модели.
В зависимости от полученных данных запускаю те или иные функции модели, гружу те или иные вьюверы.
Вроде все.
В модели я работаю только с базой данных. Результат возвращаемый моделью обычно $Q->result_array().
Этот результат в контроллере присваивается переменной:
$Data['переменная_для_вьювера'] = $this->модель->метод();
Далее масив $Data передаю в вьювер.
Во вьювере я вывожу данные=)
Если нужно подкорректировать их внешний вид использую функции хелперов.
Вроде все.

[wordwild]

Я так понимаю, намек на "выяснение отношений", это про мои посты.
Каюсь. Но если посмотрите на мои посты, там имеются ссылки на источник. В соседней ветке вы это тоже сделали, одобряю. Надеюсь это станет общепринятой практикой на этом форуме.

Насчет CI. Решил использовать фреймворк, в надежде на возможность создания приложений, которые легко вести и поддерживать. Идеологию MVC, в том или ином виде, использую давно. В CI вообще жестко - мухи отдельно, котлеты отдельно. Вот только мухи иногда прикидываются котлетами и некоторые товарищи считают это нормальным.

Как делаю я... В контроллере для каждого действия (запроса) пользователя создаю свой метод. В методах описываю реакцию на действия пользователя. Пользователь запрашивает карту сайта - значит вызываем из модели нужную функцию, передаем ей параметр - "выдать данные для карты сайта". Получаем данные, вызываем вьювер, передаем данные во вьювер. Если пользователь запрашивает страницу раздела, где есть меню с перечнем подразделов, значит в функцию модели, на этот раз передаем параметр - "выдать данные для списка подразделов для " и т.д. Если, к примеру, карту сайта нельзя смотреть незарегистрированным пользователям, то контроллер проверяет признак "залогинености" и в зависимости от результата проверки тянет из модели данные или выдает страницу ЕГГОГ. То есть контроллер, в моем случае, реализует логику приложения - что, как и когда делать.

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

Вьювер - по сути шаблон. Со всеми интерфейсными последствиями. Не пришла информация о title, выводим в теге <title> урл сайта, или вообще не выводим данный тег - тут уж как разработчик решит. Также с другими тегами. Не залогинен - форма для логина, залогинен - ссылка на личный кабинет. Вобщем все, все, все, что касается отображения. Включая жабаскрипт, цсс, картинки, верстку, что там еще...

Вот, собственно, и все. Жду каметнов. )

[pirrat]

согласен с wordwild !
Своими словами:
Контроллер - отвечает за поведение системы, т.е. на основе переданных ему данных из представления(get, post, cookie, etc) определяет что должно произойти, если данные верные(валидны) то делает запрос в модель и отдает переданные моделью данные во вью, если данные не валидны, то сразу дает команду вывести отображение с ошибкой, а так же в зависимости от отданных моделью данных, определяет какое действие произвести...
Модель - содержит всю бизнес логику, т.е. вся работа с данными происходит в ней. Модель отдает данные запрошенные контроллером, или передает свое состояние: к примеру если был запрос на зименение данных в бд, то после успешного выполнения,она сообщает контроллеру что все впорядке, итд
Отображение - Реализует всю логику вывода. И в отображениях зачастую используются Хелперы, для меня хелперы - вспомогательные функции(статические методы) которые форматируют данные, и приводят их в определенный вид. Т.е. например из модели была передана дата в формате unixstamp, так вот в отображении с помощью хелпера она будет приведена в human format/

Ну вот такое мое представление работы MVC архитектуры

[wordwild]

согласно википедии, бизнес-логика содержит алгоритмы работы приложения. а согласно книге Design Patterns, модель к алгоритмам не относится.
pirrat, где же логика? ))

[pirrat]

хорошо,можно отбросить из моего поста фразу "бизнес-логика", так как это понятие по разному интерпретируется, а все остальное оставить как я написал,вот и все, это и будет мое видение MVC =)

[wordwild]

это понятие по разному интерпретируется

можно об этом поподробнее? интересует как можно интерпретировать (вариант википедии не рассматриваем - там все понятно).