mus
Новичок
Вопрос по MVC. К чему присандалить функцию?.. (дописал, глядим)
Здравствуйте.
С недавних пор пишу, используя Code-Igniter. Вопрос, однако, по теории MVC и перекликается с Code-Ig... лишь косвенно.
Представим себе, что есть некая обыкновенная система, которая регистрирует пользователей, отправляет при этом им сообщение на e-mail с рег. данными. Администратор этой системы может редактировать пользователей и все. Для вопроса, пожалуй, достаточно.
Контроллер пользователя содержит 4 сегмента - добавление, редактирование, удаление, просмотр пользователя.
Модель пользователя содержит в себе некии оболочки для работы с базой данных, то есть набор повторяющихся команд для извлечения, компоновки данных из БД и ретурна их обратно.
Здесь я буду сильно умничать, можете мысленно послать меня куда угодно, но людям, любящим поварить в своей голове всякие абстрактные понятия ниженаписанная фигня - просто-таки пища для спора. Можем поспорить с целью прояснения в моей голове некоторых деталей, так что если вдруг я че там не так написал - прям в лоб говорим, мол не так, но и не забываем сказать, как же все-таки на самом деле обстоят дела.
Теперь по идеологии этой самой MVC-модели на основе Code-Igniter (далее CI).
Если мне нужно отправить письмо, то я могу воспользоваться:
а) стандартной функцией php
б) использовать класс для отправки письма, который содержится в стандартном комплекте CI
в) использовать хелпер для отправки письма, также содержащийся в стандартном комплекте CI. Различие класса и хелпера в том, что класс - это законченный инструмент для работы с той или иной задачей, который глобально решает задачу. Хелпер же, как маленькая отвертка - лишь расширенная функция, схожая со стандартными функциями Php, решающая задачу на чуть более высоком уровне. Разница между классом и хелпером примерно такая же, как между дрелью и отверткой. Отвертка примитивна, проста и может решить одну задачу, дрель решает эту же задачу на серьезном уровне. Изнутри дрель сложно устроена, однако на выходе это атомарный, пусть и громоздкий инструмент, который при смене насадок может как закрутить шуруп, так и закрутить его, а ещё (рассказывал кто-то), если нацепить на него обычную столовую ложку можно взбить молоко.
г) использовать плагин. Плагин - это некий атомарный класс/функция, который не является частью сего фреймворка, также не является частью системы, которая пишется на сим фреймворке, однако подключается к этому проекту как некий обособленный модуль, способный универсально решить ту или иную проблему. Пример - функция генерации пароля. В стандартном наборе этой фишки нет, подключаем извне - красота.
Теперь вдолбите в мой тупой мозг, товарищи деволоперы, к чему будет относится ФУНКЦИЯ КОМПОНОВКИ СООБЩЕНИЙ, чтоб ей мало было...
Объясняю. Представим, что после регистрации пользователя ему следует выслать данные на почту. Это задача. Начинаем разбирать на составляющие:
1) Чтобы отправить, нужна функция отправки. Не заморачиваемся, отправляем функцией хелпера send_email('получатель', 'тема', 'сообщение')
2) Получатель у нас получается при регистрации, тема и сообщение, по требованиям, должны иметь возможность редактироваться администратором, ибо тут будет менять сию информацию в зависимости от лунных дней и личного гороскопа, чтоб ему мало было...
3) Так как требования его обоснованы, что бы я там не говорил, определяем, где держать шаблон темы и сообщения. Так как редактироваться сие должно из под веб-интерфейса, у нас есть три варианта:
а) тупо определить файл шаблона, положить его в папочку templates/letters и дальнейшие манипуляции проводить с этим самым файлом.
б) определить в базе данных таблицу для этих параметров (тема, сообщение)
в) определить в конфиг файле такие параметры, как леттер => array('subj' => 'Hello', 'mess' => 'How are you?');
Вариант А (Файл шаблона), признаться откровенно, будет сбоку припеку, ибо придется делать функции для работы с файлами и т.д.
Вариант Б рушит в моей голове понимание базы данных в рамках веба и этой MVC, ибо мне всегда казалось, что база идеологически предназначена для хранения многомерной информации. А хранить в ней, по сути, какую-то админску настройку - че-то как-то не то. Чувствую, что не то, но понять не могу, почему мне кажется, что это не то. Да-да, вот такой дурак
Поэтому третий вариант всем хорош, потому как:
* средствами системы поддерживается удобная работа со всеми конфигами. Конфиг файлы определены изначально.
* можно создать свой конфиг файл.
* поддерживаются просто реализованные возможности извлечения и добавления данных.
4) Зная, где хранить, переходим к компоновке. Итак, вот здесь как раз главный вопрос - КАКАЯ ФУНКЦИЯ, ПО ИДЕЕ, ДОЛЖНА КОМПОНОВАТЬ ВСЕ ЭТИ ДАННЫЕ?..
Иными словами, эта функция должна (а может эта функция и должна быть разбита на несколько частей, щас не суть):
1) получить данные шаблона (гет фром конфиг)
2) произвести замену в шаблоне
3) сретурнить эти данные в переменные, которые потом подставятся в send_email.
По логике, эта функция (компоновка) не часть модели класса User, ибо ее и Админ может использовать в своем контроллере.
Функция не атомарна, так как зависит от моей логики подачи данных из псевдошаблона_конфиганасамомоделе. То есть - это автоматом не плагин.
Теперь вот такой ещё вопрос (устал писать...)
Народ, в качестве чего определять вот такие вот функции, которые по сути своей лишь оболочки для нескольких действий?..
Эти функции не хелпер, использовать их отдельно от той субъективной логики подачи данных из шаблона невозможно.
Они и не часть модели, ибо использовать их можно и в другой модели...
Не вяжется че-т у меня ниче в голове...
Вообще не обижусь, если сходу тему закроют за неправильным или излишне громоздким оформлением.
Но если хоть кто-то че-то по делу ответит - реально буду рад.
Респект программерам!..
Здравствуйте.
С недавних пор пишу, используя Code-Igniter. Вопрос, однако, по теории MVC и перекликается с Code-Ig... лишь косвенно.
Представим себе, что есть некая обыкновенная система, которая регистрирует пользователей, отправляет при этом им сообщение на e-mail с рег. данными. Администратор этой системы может редактировать пользователей и все. Для вопроса, пожалуй, достаточно.
Контроллер пользователя содержит 4 сегмента - добавление, редактирование, удаление, просмотр пользователя.
Модель пользователя содержит в себе некии оболочки для работы с базой данных, то есть набор повторяющихся команд для извлечения, компоновки данных из БД и ретурна их обратно.
Здесь я буду сильно умничать, можете мысленно послать меня куда угодно, но людям, любящим поварить в своей голове всякие абстрактные понятия ниженаписанная фигня - просто-таки пища для спора. Можем поспорить с целью прояснения в моей голове некоторых деталей, так что если вдруг я че там не так написал - прям в лоб говорим, мол не так, но и не забываем сказать, как же все-таки на самом деле обстоят дела.
Теперь по идеологии этой самой MVC-модели на основе Code-Igniter (далее CI).
Если мне нужно отправить письмо, то я могу воспользоваться:
а) стандартной функцией php
б) использовать класс для отправки письма, который содержится в стандартном комплекте CI
в) использовать хелпер для отправки письма, также содержащийся в стандартном комплекте CI. Различие класса и хелпера в том, что класс - это законченный инструмент для работы с той или иной задачей, который глобально решает задачу. Хелпер же, как маленькая отвертка - лишь расширенная функция, схожая со стандартными функциями Php, решающая задачу на чуть более высоком уровне. Разница между классом и хелпером примерно такая же, как между дрелью и отверткой. Отвертка примитивна, проста и может решить одну задачу, дрель решает эту же задачу на серьезном уровне. Изнутри дрель сложно устроена, однако на выходе это атомарный, пусть и громоздкий инструмент, который при смене насадок может как закрутить шуруп, так и закрутить его, а ещё (рассказывал кто-то), если нацепить на него обычную столовую ложку можно взбить молоко.
г) использовать плагин. Плагин - это некий атомарный класс/функция, который не является частью сего фреймворка, также не является частью системы, которая пишется на сим фреймворке, однако подключается к этому проекту как некий обособленный модуль, способный универсально решить ту или иную проблему. Пример - функция генерации пароля. В стандартном наборе этой фишки нет, подключаем извне - красота.
Теперь вдолбите в мой тупой мозг, товарищи деволоперы, к чему будет относится ФУНКЦИЯ КОМПОНОВКИ СООБЩЕНИЙ, чтоб ей мало было...
Объясняю. Представим, что после регистрации пользователя ему следует выслать данные на почту. Это задача. Начинаем разбирать на составляющие:
1) Чтобы отправить, нужна функция отправки. Не заморачиваемся, отправляем функцией хелпера send_email('получатель', 'тема', 'сообщение')
2) Получатель у нас получается при регистрации, тема и сообщение, по требованиям, должны иметь возможность редактироваться администратором, ибо тут будет менять сию информацию в зависимости от лунных дней и личного гороскопа, чтоб ему мало было...
3) Так как требования его обоснованы, что бы я там не говорил, определяем, где держать шаблон темы и сообщения. Так как редактироваться сие должно из под веб-интерфейса, у нас есть три варианта:
а) тупо определить файл шаблона, положить его в папочку templates/letters и дальнейшие манипуляции проводить с этим самым файлом.
б) определить в базе данных таблицу для этих параметров (тема, сообщение)
в) определить в конфиг файле такие параметры, как леттер => array('subj' => 'Hello', 'mess' => 'How are you?');
Вариант А (Файл шаблона), признаться откровенно, будет сбоку припеку, ибо придется делать функции для работы с файлами и т.д.
Вариант Б рушит в моей голове понимание базы данных в рамках веба и этой MVC, ибо мне всегда казалось, что база идеологически предназначена для хранения многомерной информации. А хранить в ней, по сути, какую-то админску настройку - че-то как-то не то. Чувствую, что не то, но понять не могу, почему мне кажется, что это не то. Да-да, вот такой дурак
Поэтому третий вариант всем хорош, потому как:
* средствами системы поддерживается удобная работа со всеми конфигами. Конфиг файлы определены изначально.
* можно создать свой конфиг файл.
* поддерживаются просто реализованные возможности извлечения и добавления данных.
4) Зная, где хранить, переходим к компоновке. Итак, вот здесь как раз главный вопрос - КАКАЯ ФУНКЦИЯ, ПО ИДЕЕ, ДОЛЖНА КОМПОНОВАТЬ ВСЕ ЭТИ ДАННЫЕ?..
Иными словами, эта функция должна (а может эта функция и должна быть разбита на несколько частей, щас не суть):
1) получить данные шаблона (гет фром конфиг)
2) произвести замену в шаблоне
3) сретурнить эти данные в переменные, которые потом подставятся в send_email.
По логике, эта функция (компоновка) не часть модели класса User, ибо ее и Админ может использовать в своем контроллере.
Функция не атомарна, так как зависит от моей логики подачи данных из псевдошаблона_конфиганасамомоделе. То есть - это автоматом не плагин.
Теперь вот такой ещё вопрос (устал писать...)
Народ, в качестве чего определять вот такие вот функции, которые по сути своей лишь оболочки для нескольких действий?..
Эти функции не хелпер, использовать их отдельно от той субъективной логики подачи данных из шаблона невозможно.
Они и не часть модели, ибо использовать их можно и в другой модели...
Не вяжется че-т у меня ниче в голове...
Вообще не обижусь, если сходу тему закроют за неправильным или излишне громоздким оформлением.
Но если хоть кто-то че-то по делу ответит - реально буду рад.
Респект программерам!
..
