Антон Натаров Но Depencdency Injection и подразумевает следованию принципу единственной обязанности, каждый класс делает что-то одно и делает это хорошо (одна причина для изменения). А вы предлагаете что модели в слое представления mvc могут содержать атрибуты для представления бизнес-данных и могут содержать методы с реализацией бизнес-логики. Вы потом этот объект отдаете представлению?
Александр Макаров в папке common/models/ лежит и User и LoginForm этож каша будет когда проект будет большой? если еще будет класс post и нужно будет получить все посты юзера, куда писать метод getPostsbyUser в юзер или пост? и это только две сущности а что если их будет много, то не понятно где искать нужный запрос если сам не писал его... мне кажется такой подход прививает писать код с душком изначально.
Александр Макаров а если понадобится еще один слой отображения данных (например rest api для мобильного приложения) то нужно будет копировать всю доменную модель в новый проект или использовать первый как собсвенно сам домен?
Антон Натаров городить его не стоит а вот вынести работу с бд в отдельный слой думаю стоит, имхо это не усложнит проект а наоборот разрулит его ))) у вас всегда есть 100% уверенность что маленький проект не станет большим или в нем не будет координальных изменений?
Антон Натаров "Но не стоит простое приложение - делать более сложным, потому что так пишут в книгах." Мне кажется что в книгах как раз пишут как из сложного, жестко связанного и не понятного кода сделать простой и легко поддерживаемый код. разве нет?
Антон Натаров могут содержать атрибуты для представления бизнес-данных; могут содержать методы с реализацией бизнес-логики; а как же принцип единственной обязанности ?