Модели в паттернах MVC/MVP?

Question

[Александр Рублев]

Всем привет, пытаюсь разобраться с паттернами MVC и MVP.
Пишу десктопное большое приложение(точнее собираюсь переписывать).
Вроде бы понимаю эти паттерны, но хочу разобраться в одном моменте.
На сколько я понял, модель это объект класса который предоставляет данные и логику для view.

Например работаем с работниками на предприятии:
Есть класс WorkerModel, в котором описан работник и методы для работы с ним.
Но что если мне необходимо вывести список всех работников, и например посчитать сколько уволенных, или еще что то.Я так понимаю мне надо создать новую модель типа WorkerListModel, в котором уже будут методы для работы со списком работников, и например подсчета уволенных, и так далее?

Пишу простым языком, так что не ругайтесь.

Comments

[Антон Р.]

Я так понимаю мне надо создать новую модель типа WorkerListModel, в котором уже будут методы для работы со списком работников, и например подсчета уволенных, и так далее?

- создай модель WorkerService и в нем методы типа getList, firedList и т.д., типа Отдел кадров, он за всё такое и будет отвечать. Типа как в реальной жизни.

[Александр Рублев]

Антон Р., Хм красивая идея)),
Может подскажите тогда, когда например я в списке выберу работника для редактирования, то в новом окне я перейду на модель Worker, и буду работать уже только с ним?

[Антон Р.]

Александр Рублев, можешь передать модель Worker внутрь модели WorkerService в метод EditWorker и потом этот сервис с помощью этого метода его редактирует.

Но я подсказывальщик еще тот )

<?php

// Здесь еще класс Worker должен быть

class WorkerService {
	
	public function editWorker($worker_id){
		$worker = new Worker($worker_id);
		$worker->department = 'Цех №5'; // меняем ему место работы
		$this->save($worker);
	}

public function save(){
//...
}

}

[Антон Р.]

Вот попробуй запустить в песочнице phptester.net

<?php

class Worker {
	
	public $id;
	public $name;
	public $department;
	
	public function __construct($id, $name, $department){
		$this->id = $id;
		$this->name = $name;
		$this->department = $department;
	}
	
}

class WorkerService {
	
	public function editWorker($worker_id){
		
		// Достаём из базы работника по id
		
		$worker = new Worker(1, 'Вася', 'Цех №3'); // Заполняем данными из базы
		$worker->department = 'Цех №5'; // меняем ему место работы
		$this->save();
		
	}
	
	public function save(){
		// Сохраняем в базу.

		echo 'Сохранен!';
		
	}

}

$workservice = new WorkerService();
$workservice->editWorker(1);

[Максим Федоров]

Антон Р.,

WorkerService

буээээ

Repository, забудьте вы о суффиксах Service

[Антон Р.]

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

[Антон Р.]

Максим Федоров, окей.

[kafkiansky]

Максим Федоров, там, где вы это прочитали, говорят забыть про все суффиксы, а не только Service. И при чем здесь вообще Repository? У него типичная AR модель.

[Евгений Ромашкан]

Антон Р.,

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

Это Information Expert из GRASP, но у вашего сервиса в принципе нету собственного состояния, потому об "обладает более полной информацией" речи быть не может.

[Максим Федоров]

kafkiansky, про репозиторий — у автора задача получить список моделей, видимо что-то перепутал

[kafkiansky]

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

[Максим Федоров]

Антон Р.,

Не помню как называется принцип но в общем смысл - задачей должен заниматься объект обладающий наиболее полной информацией для этого действия

Если WorkerService создает, редактирует некие данные, то данные должны быть в нем... соответственно весь код из Worker попадет в этот сервис... затем мы переименуем WorkerService -> Worker и получим нормальный объект, соблюдем Information Expert из GRASP, получим отличную инкапсуляцию (одна из основ ООП) и хорошую внутреннюю связанность (cohesion) и низкую внешнюю (coupling) — это еще пара принципов из того же GRASP, получим единую ответственность (S из SOLID)... а все что не относится к нашей абстракции (сохранение например) — вынесем в слой приложения (в некий сервис)

[Максим Федоров]

Антон Р., более опытные программисты совершают все те же шаги, что и вы (да почти везде эта лапша процедурная в ООП обертке)

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

Я вот написал на похожую тему статью на Хабре Геттеры/сеттеры и проблема с инкапсуляцией в Symfo...
Дмитрий там тоже отписался (для аппеляции к вашим авторитетам)

[Антон Р.]

Максим Федоров,

а все что не относится к нашей абстракции (сохранение например) — вынесем в слой приложения (в некий сервис)

- как это примерно всё может выглядеть в коде?

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

- это в его блоге или в видео-курсе?

Answer 1

[Максим Федоров]

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

Вам поможет такой паттерн, как Repository
Для каждой модели создается некий класс, который инкапсулирует в себя детали как и с помощью чего он это делает (через SQL или из памяти, через ORM или без) и отдает всего лишь коллекции/массивы нужных вам готовых обьектов)

Примерно как-то так:

class WorkerRepository(object):
     def __init__(self, DBSession)

     def get_dismissed_count(self, count)

     def get_all(self)

Пример: jordifierro.com/django-clean-architecture
Тут примеры на Джанго, но на самом деле архитектура приведена из книги Роберта Мартина и относится и архитектуре десктоп-приложений, особенно присмотритесь к тому, как там организованы репозитории

Comments

[Александр Рублев]

Спасибо за ответ, я знаю про репозиторий, и даже использую его с ОРМ.
Да мне нужно получить список моделей, но так же мне нужно предоставить данные для вставки в таблицу, например ID, Имя, Фамилия, дата рождения (или например по требованию пользователя добавить колонки). Так же мне нужно их отсортировывать например по вакансиям, или отфильтовывать по имени, или например удалить выбранного работника, или например копировать запись, или предоставить кол-во работников, стаж которых более года, или еще что нибудь. То есть работа со списком будет происходить.

[Максим Федоров]

Александр Рублев, все же логику получения (хоть по каким критерием) — задача репозитория, при этом критерии же можно представлять не в виде разных методов, а сделать один, который примет аргументы (например сортировать как) или лимит... при этом это может быть отдельный объект критерия, который и займется сборкой запроса для метода репозитория

[Максим Федоров]

Александр Рублев, а вот удалить/копировать — это уже логика отдельная

[Александр Рублев]

Максим Федоров, Спасибо за ответы

все же логику получения (хоть по каким критерием) — задача репозитория,

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