MVC, ООП — какие должны быть сущности и связи, для такой задачи?

Question

[topuserman]

У меня такая задача: есть удаленный сервис, куда ежедневно выкладывают XML-файл с новостями (сам файл достаточно объемный ~ 50 МБ).

Задача: сделать обычную страницу, куда будет выводиться список новостей (заголовок, и мини описание), и каждую новость можно детально посмотреть, перейдя по ссылке. Также реализовать постраничную навигацию.

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

Как я себе это представляю:

Для начала нужно xml-файл загружать в таблицу БД - этим будет заниматься консольный скрипт, который будет запускаться по крону, как я понимаю, должен быть реализован:
- класс который скачивает файл разбирает его items, и каждый item переводит в объект типа NewsEntity, затем сущности новостей (NewsEntity) будут через какой-то класс импортироваться в БД - такой класс вроде называется Repository ? И как нужно импортировать сущности новостей в БД через Repository: собирать сущности в массив потом массово импортировать ? или каждую сущность по отдельности ? как это делается, можно пример пожалуйста ?

примерная файловая структура:

/bin/xml_news_import.php - скрипт импорта новостей по крону
/src/XmlNewsParser.php - класс который парсит новости из XML файла
/src/Entity/NewsItemEntity.php - сущность новости
/src/Repository/NewsRepository.php - класс который будет работать с коллекцией NewsItemEntity (загрузка в таблицу БД, выборки и т.д.)

А как дальше правильно делать отображение данных в виде списка, и детальной странице - не понимаю..

Должен быть один контроллер - который запускает отображение списком и детальное ?
Или несколько ?

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

Answer 1

[Северное Сияние]

я только изучаю mvc

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

Answer 2

[synapse_people]

Контроллер как-то так:

class News {
function index($page) {}
function show($id) {}
}

Если используете Entity+Repository, то советую сделать еще Service, который будет доставать данные из Repositry (и содержать всю логику). Сам этот Service будет доступен из Controller. (так сделано в Spring Framework).

Если только Model, то в ней должна быть логика вся и доставания записей из БД, обработка и тд.

В контроллере формируются данные для View, например, массив. А View только его отрисовывает.

Как-то так..

Comments

[topuserman]

спасибо!

Если используете Entity+Repository, то советую сделать еще Service

а как еще бывает?

Правильно понимаю, что Model - это упрощенная версия, а Repository + Service - это разложение модели на слои ?

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

[synapse_people]

topuserman, я советую посмотреть как сделано в Spring Framework (WebMVC)
там куча демо проектов, туториалов от кого захочешь,
по архитектуре +- все хорошо

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

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

Answer 3

[dmitriy]

понадобятся:
Controller
NewsService
NewsRepository
NewsEntity
NewsCollection
SearchCriteria

1. Реализуем Domain
Domains/News
- Contracts/SearchCriteriaInterface.php имеет методы навигации, фильтров, сортировки getLimit, getPage, getFilterById и тд
- Contracts/NewsRepositoryInterface.php имеет методы работы с хранилищем findById, findByCriteria и тд
- NewsService.php , бизнес логика тут, создаем методы
__construct(NewsRepositoryInterface $repository)
getById(int $id): NewsEntity
getBySearchCriteria(SearchCriteriaInterface $criteria): NewsCollection

- NewsEntity.php , обычная DTO с сеттерами и геттерами (все что осталось от модели)
- NewsCollection.php, коллекция содержащая список NewsEntity с методами интерфейсов Iterator,ArrayAccess,Countable

2. Реализуем Application
Application/Controllers
- HomeController.php содержит методы списка новостей и одной новости, но моно создать два контроллера со списком и с детальной инфой, все на ваше усмотрение.
__construct(NewService $service, Request $request)
index() - метод основной или на ваше усмотрение, который получает коллекцию новостей пример

$criteria = new \Infrastructure\Repositories\News\SearchCriteria;
$criteria->setLimit(10);
 
$newsCollection = $this->service->getBySearchCriteria($criteria);
//далее куда угодно отправляем $newsCollection или в шаблон или в JsonResponce и тд

- show(int $id), реализация страницы новости
$newsEntity = $this->service->getById($id);

3. Реализуем Infrastructure
Infrastructure/Repositories/News/
- SearchCriteria.php реализация интерфейса SearchCriteriaInterface
- NewsRepository.php реализация интерфейса NewsRepositoryInterface

3 этап на момент тестирования можно реализовать функционал не работая с источниками данных, то есть можно использовать заранее созданный сущности в специальных Mock репозиториях. Инжектить можно через DI, такая схема позволить покрыть код unit тестами
Плюс такого подхода что код разрабатываем не от слоя хранения а от бизнес сущностей, SOLID и все такое

Comments

[Сергей]

NewsService
NewsRepository
NewsEntity
NewsCollection
SearchCriteria

Или одна модель)
Так я никогда и не пойму зачем люди усложняют себе жизни какими-то репозиториями, сервисами

[synapse_people]

Сергей, это приходит со временем :)