Нужно преобразовывать таблицу в Excel в таблицу HTML (расписание в вузе).
Вопросов два:
1. Есть ли какие-либо внятные туториалы по phpexcel или по бандлам, которые его используют (я использую liuggio/ExcelBundle)?
2. Как правильно сформировать MVC-структуру с Excel? Сами выборки из файла должны быть в репозитории, так понимаю? Либо в сервисе? Тогда нужны ли сущности какие-либо и как они должны выглядеть?
Сущности - это ваши бизнес-объекты. Если мы конечно говорим о сущностях а не о энтитях доктрины (те могут быть бизнес-объектами, особенно если вы используете Doctrine 2.5, но все же там немножко другое).
Репозиторий - это отделение логики хранения данных от их использования.
Остаются сервисы. В идеале у вас есть DTO, которое перемещается между PhpExcel и вашим кодом. Этот самый DTO умеет переваривать только ваше приложение и сервис для работы с PHPExcel.
OnYourLips: все относительно. Я считаю что контроллеры тут лишнее звено. Они должны лишь просить сервисный слой приложения что-то сделать и конвертить данные в формат запроса (HTTP, CLI, etc) в формат, который едят сервисы. А уж от-туда все управление и происходит.
За документацией вам сюда
А вот во втором вопросе просматривается полное непонимание матчасти, почитайте про MVC побольше, про организацию бизнес-логики.
Репозитории и сущности тут совсем не при чем.
Я более-менее знаю, что такое MVC в его базовом виде. Да, с его представлением в Symfony работаю не слишком много.
Из опыта изучения - понимаю, что сущности и репозитории здесь не подходят по той причине, что данные я лишь получаю. Сущность, она же модель - позволяет работать с данными в обе стороны, как получать, так и извлекать. Репозиторий - позволяет производить какие-либо достаточно сложные действия или выборки сущностей - по сути, является набором функций.
Да, я могу быть неправ, если что - буду благоден за исправление или наставление на путь истинный.
По части темы - здесь напрашивается именно сервис, так как мне нужно получить "удаленные" данные откуда-то.
thatside: открою вам страшную тайну (уже надоело на самом деле ее открывать) - Symfony не совсем MVC фреймворк. MVC это вообще чисто UI- ная архитектура.
И да, сущность != модель, это часть модели. А с учетом того что на 99% у вас сущности состоят из геттеров/сеттеров... Ну вы меня поняли.
В любом случае сущность это ваши данные. В идеале она содержит так же и логику работу с этими данными (гуглить "информационный эксперт"). В еще более идеальном мире сущности не нужно валидировать, так как у вас в принципе не должно быть никакой возможности привести сущность к невалидному состоянию.
Репозитории нужны для организации persistence ignorance. В идеале для каждой сущности должен быть свой репозиторий в виде интерфейса, а то что предоставляет вам доктрина - это более низкоуровневая штука.
То что вы описываете - просто работа с данными, причем не с вашими бизнес объектами... а как с данными запроса, или еще что-то подобное. Обычно в таком случае формируют Data-transfer object под ваши нужды, содержащие все необходимые данные, и за счет них происходит обмен данными. Грубо говоря - все инкапсулируется в сервис. Для кода который этот сервис использует должно быть фиалетово откуда берутся данные.
Сергей Протько: то, что не совсем MVC - это, в принципе, успел уловить.
По поводу моделей - читал про два разных подхода к ним: тонкая модель - собственно, только геттеры-сеттеры, и толстая модель, которая хранит как раз таки логику. В Symfony это первый вариант, я же, когда изучал MVC, реализовывал второй вариант.
Почитал про persistence ignorance. Если так подумать, то репозиторий + тонкая модель ≈ толстая модель, ведь так?
Да, согласен, это только данные, которые нельзя расценивать как бизнес-объект - приблизительно такой подход и планировал для себя, когда еще раз подумал.
thatside: репозиторий никакого отношения к модели не имеет. И да, то как вы реализуете модель - это чисто ваше дело. Вы можете и на Yii/Laravel с их ActiveRecord сделать полноценную толстую модель и использовать модельки в контексте AR чисто как DTO. Начиная с версии 2.5 (что только недавно вышла) юзать VO в сущностях доктрины перестало быть болью и теперь можно спокойно делать жирные модели.
