Что входит в обязанности «тонкого контроллера» и как при нем происходит связь вида с моделью?

Question

[vasIvas]

Начав изучать вэб я столкнулся с перевернутым миром mvc. Я не буду писать свое видение mvc ( пока ), а сразу попрошу рассказать, что входит в обязанности "тонкого контроллера" и как при нем происходит связь вида с моделью?

Answer 1

[Павел Соловьёв]

всю логику запиливаешь в сервисы, а в контроллёре вызываешь только необходимые методы из этих сервисов.

Comments

[vasIvas]

@pavel_salauyou, как Вы могли узнать из моих слов, в вэбе я новичок и со словом сервис на деле не сталкивался. И можно вас попросить немного раскрыть тему?)

[Павел Соловьёв]

сервис в данном контексте это просто класс, который берёт на себя всю работу, он вызывает нужные вам методы, например:

class Controller
{
public function indexAction()
{
$service = new PostService();
$posts = $service->findAll();
$publishedPosts = $service->findPublished();
return $this->render('template.html', ['posts' => $posts]);
}
}

т.е в данном примере контроллёр работает с одной сущностью сервисом PostService. Вообще это очень очень простой пример, чтобы в целом въехать нужно книжки по проектированию читать.

[vasIvas]

А вот этот простой класс, он действительно простой, или шаблонный? Шаблонный я имею ввиду Proxy или возможно Adapter, который имеет определенный набор методов, адаптированных алгоритмически под контроллер и в которых и реализуется те же, допустим, выбор из коллекции сообщений?

[Павел Соловьёв]

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

[Дмитрий Б]

@pavel_salauyou скажите пожалуйста, в вашем примере слишком простой сервис, поиск только опубликованных постов ($service->findPublished();).
А что, если выборка должна быть на порядок более сложная? Вдруг нужно выбрать опубликованные посты за определённый промежуток времени от нного пользователя? Как подобное реализовать?
Так правильно?

class PostService
{
	public function findPosts($params = [])
	{
		$postsCriteria = new CDbCriteria;

		if (!empty($params['active'])) {
			$postsCriteria->addColumnCondition(['active' => '1']);
		}

		if (!empty($params['author_id'])) {
			$postsCriteria->addColumnCondition(['author_id' => $params['author_id']]);
		}

		if (!empty($params['order'])) {
			switch ($params['order']) {
				case 'time_send': $order = 'send_date';
					break;
				case 'time_edit': $order = 'edit_date';
					break;
				default: $order = 'id';
			}

			$postsCriteria->order = $order.' ASC';
		}
		
		return PostService::model()->findAll($postsCriteria);
	}
}

[Дмитрий Б]

Может скопы использовать или ещё как?

[Павел Соловьёв]

@PiloTeZ можно и так, если будут только эти данные, а вообще если условий станет много, я бы я вынес в отдельные методы

$postService->findByStatus(1)->orderBy('asc')->all();
$postService->findByAuthor()->get();

или

$postService->filter(['status' => 1])->all();

[Дмитрий Б]

@pavel_salauyou то есть скоупы не нарушают принципов MVC? Если так, то это отличное решение!
Спасибо! Меня этот вопрос очень волновал

[Павел Соловьёв]

@PiloTeZ почитай про SOLID

[Дмитрий Б]

@pavel_salauyou спасибо )) Нашел интересное для себя

Answer 2

[bromzh]

Но в объектно-ориентированном программировании используется активная модель MVC, где модель — это не только совокупность кода доступа к данным и СУБД, но и вся бизнес-логика. Следует отметить возможность модели инкапсулировать в себе другие модели. В свою очередь, контроллеры представляют собой лишь элементы системы, в чьи непосредственные обязанности входит приём данных из запроса и передача их другим элементам системы. Только в этом случае контроллер становится «тонким» и выполняет исключительно функцию связующего звена (glue layer) между отдельными компонентами системы.

Как это можно было не заметить на википедии?

Comments

[vasIvas]

А что тут именно "это"?

[bromzh]

Ответ на твой вопрос.

[vasIvas]

Если Вас спросить - "как контроллер связывает вид с моделью" то ответ "связывает" Вы будете считать исчерпывающим?
Как он связывает?

[bromzh]

Ты как маленький, всё надо разжевать и в рот положить.
В обычном MVC из вьюхи приходят данные этой вьюхи. Вьюха может быть, например, формой в десктопном приложении, или на сайте, тут будет меняться только способ отправки и приёма данных. Контроллер принимает эти данные, и отправляет их нужным методам модели. Вся логика по обработке или преобразованию этих данных в находится в моделях. Методы модели могут вернуть некоторые данные обратно в контроллер. Тут он опять выполнит функцию передатчика и отправит данные нужным вьюхам или другим моделям.
Понимаешь суть? Вьюхи знают только как отображать поступившие данные. Модели знают только как обрабатывать поступившие данные. Контроллеры знают только как перенаправлять данные в оба направления.
Получается такая цепочка: юзер -> V -> C -> M -> C -> V -> юзер.

[vasIvas]

Для Вас разжевывать === дать ответ на вопрос?) Я неспроста попросил объяснить, так как описанная Вами концепция MVC, где вид не имеет ссылки на модель, а контроллер является прими-отдай между видом и моделью, во многих, а точнее сказать, в половине статей называется MVP.