thatside: репозиторий никакого отношения к модели не имеет. И да, то как вы реализуете модель - это чисто ваше дело. Вы можете и на Yii/Laravel с их ActiveRecord сделать полноценную толстую модель и использовать модельки в контексте AR чисто как DTO. Начиная с версии 2.5 (что только недавно вышла) юзать VO в сущностях доктрины перестало быть болью и теперь можно спокойно делать жирные модели.
vldud: а нет, у вас там preventDefault... ну короче нужно думать. И посмотрите на реализацию сервиса $parse в Angular. И вообще стоит уже думать в сторону webcomponents и подобного.
vldud: минусы в плане производительности - никаких, можно с таким же успехом делегировать события на элементы выше и т.д. Тут другой вопрос, что в таком виде это не юзабельно особо. Слишком специфичное решение, только под ваши нужды.
OnYourLips: все относительно. Я считаю что контроллеры тут лишнее звено. Они должны лишь просить сервисный слой приложения что-то сделать и конвертить данные в формат запроса (HTTP, CLI, etc) в формат, который едят сервисы. А уж от-туда все управление и происходит.
thatside: открою вам страшную тайну (уже надоело на самом деле ее открывать) - Symfony не совсем MVC фреймворк. MVC это вообще чисто UI- ная архитектура.
И да, сущность != модель, это часть модели. А с учетом того что на 99% у вас сущности состоят из геттеров/сеттеров... Ну вы меня поняли.
В любом случае сущность это ваши данные. В идеале она содержит так же и логику работу с этими данными (гуглить "информационный эксперт"). В еще более идеальном мире сущности не нужно валидировать, так как у вас в принципе не должно быть никакой возможности привести сущность к невалидному состоянию.
Репозитории нужны для организации persistence ignorance. В идеале для каждой сущности должен быть свой репозиторий в виде интерфейса, а то что предоставляет вам доктрина - это более низкоуровневая штука.
То что вы описываете - просто работа с данными, причем не с вашими бизнес объектами... а как с данными запроса, или еще что-то подобное. Обычно в таком случае формируют Data-transfer object под ваши нужды, содержащие все необходимые данные, и за счет них происходит обмен данными. Грубо говоря - все инкапсулируется в сервис. Для кода который этот сервис использует должно быть фиалетово откуда берутся данные.
ColdSpirit: ну так вам нужно просто разбить на строки, найти ключ и делить значения... для этого регулярки не подходят. Они подойдут что бы проверсти нормализацию текста, разобрать все на лексемы отдельные.
HaruAtari: проблема в том что я не знаю скалу и крайне плохо ее читаю, но судя по документации к slick-у у вас все объекты являются проекцией таблицы на объекты.. Эдакие DTO для сохранения/выборки из базы...
Грубо говоря Slick это просто абстракция над базами данных предоставляющая вам доступ к данным таблицы через объекты, но это не то что я вам описывал... это более низкоуровневая штука. Я вам говорил про ORM реализующий data-mapping, то есть данные таблицы мэпятся на ваши объекты по определенным правилам. То есть реализовывать сохранение и загрузуку из базы придется самостоятельно через slick. Я бы всю работу с этими объектами пихал в репозитории что бы не раскидывать зависимости от slick по коду.
В целом... наверное стоит по подробнее почитать как это все готовят вместе, ибо я подозреваю что отличий от типичной структуры Java приложений хватает.
HaruAtari: что-то типа того. Только вместо того что бы реализовывать методы сохранения и загрузки - воспользуйтесь каким-нибудь Hibernate ORM и в целом почитайте про data-mapper, шаблон репозиторий и т.д.
