Sassoft
@Sassoft
Yii developer

Веб приложение на Symfony Components, как правильно?

Приветствую всех!

Решил в целях обучения написать простое веб приложение для регистрации и авторизации пользователей.
Задача - поработать со сторонними библиотеками и не использовать фреймворки (сам пишу на Yii).
Есть только голый PHP и Composer.

Стал смотреть как можно решить следующие задачи:
1) Приложение имеет FrontController, использовать роутинг.
2) Namspaces, автолоад библиотек - все чтоб красиво было.
3) Разделить приложение по паттерну MVC, прикрутить ORM, шаблонизатор для вывода, использовать bootstrap для верстки, написать сущность Пользователь с методами авторизация, регистрация.
4) Если будет готовое сделать миграции чтоб можно было разворачивать проект.
5) Написать юнит тесты и приемочные тесты

Почитал что все практически это можно сделать на библиотеках Symfony, ну ок почему бы и нет.
Выбрал библиотеки:
ClassLoader,HttpKernel,Form,Security, Propel ORM.

Вопросы:
Вроде и примеры есть и все ок и легко, но все же Symfony не пропагандирует MVC и слоя такого как модель нет (в отличие допустим от Yii).
Тогда как поступить с этим? Есть компонент форм для валидации данных и заполнения полей авторизации-регистрации, есть ORM а как мне связать и валидацию и записи через ORM в объект User допустим.
Как сделать правильно с точки зрения логики?

Также вопрос по шаблонизатору, что порекомендуете?
Думаю что для авторизации и аутентификации также использовать соответсвующие компоненты, или уже перебор?
  • Вопрос задан
  • 739 просмотров
Решения вопроса 3
benbor
@benbor
Помог ответ - не забудь лайкнуть
Если уж, вы так хотите разобраться в построении своих велосипедов, а тем более, велосипед конструкторов (вы ж собираетесь юзать библиотеки), попробуйте Silex. Это микрофреймворк, у которого есть только httpkernel, router, Container. Написано это в 2-х файлах, чтоли ))) так что, если разберетесь как там что реализовано, будет крупнейший опыт.
А любое подключение библиотеки Symfony , через свой ServiceProvider ( не готовый!) превратиться в прекрасные вечера проведенные в дебрях кода этих самых библиотек :).
PS. Все описанное выше пробовал сам лично - результат огонь
Ответ написан
arutyunov
@arutyunov
Mooza.ru — Делаем сайты
По поводу шаблонизатора - можно Twig попробовать. Он от разработчиков Симфони.
Ответ написан
lexxpavlov
@lexxpavlov
Программист, преподаватель
1) По поводу моделей.
Symfony не пропагандирует MVC и слоя такого как модель нет

На самом деле, Symfony хотя и не пропагандирует MVC (потому что есть MVVM, например), но легко может использоваться с MVC, всё для этого в ней есть. Единственно чего нет в Symfony - нет готового решения моделей. Почему - потому как разные ОРМы будут использовать разные решения. Но я рекомендую использовать Доктрину, в ней вообще не нужно думать о сложных моделях - просто делайте plain-php класс для объекта, без специальных базовых классов для модели.
class Person {
    public $firstname;
    public $lastname;
}

и этого достаточно. А доктрина умеет взять это и создать таблицу базу данных, получать оттуда в список записей, создавать новые и пр. Лучше, конечно, в классе поля сделать приватными, сделать геттеры/сеттеры, возможно - добавить методы бизнес-логики. Многие любят прямо в классе модели указывать метаданные полей (тип данных в БД) с помощью аннотаций, а некоторые переносят в отдельный yml-файл.

В общем, раз хотите учиться - берите Doctrine2. Возможно, он работает медленнее, но зато даёт очень удобное создание моделей.

2) По поводу шаблонизатора. Берите Twig. Он прекрасен. Удобно создавать свои функции, легко наследовать и переопределять блоки.

3) Валидацию моделей можно делать двумя способами - валидировать формы или валидировать модель. Начните с валидации форм, в симфонии это делается достаточно легко.

4) Авторизацию с аутентификацией тоже можно использовать симфониевскую - компонент Security.

5) Не забудьте взять компоненты DependencyInjection, Config, OptionsResolver, Yaml. Подумайте ещё о Routing, Translation, Debug, EventDispatcher, Intl и Validator. И тогда у вас получится Symfony Framework :)
Ответ написан
Пригласить эксперта
Ответы на вопрос 2
Fesor
@Fesor
Full-stack developer (Symfony, Angular)
Разделить приложение по паттерну MVC,


Ваш MVC плавно превращается в MVA, а MVA плавно превращается в луковую архитектуру.

и слоя такого как модель нет

Потому что модель это не слой, это объект. Один одинешенек (в контексте одного реквеста) такой... его задача взять запрос и выплюнуть данные. То есть для контроллера модель это сервис, для шаблона модель это... сущности или DTO.

Модель это ВСЕ ЧТО УГОДНО что умеет обрабатывать данные и содержит их.

Symfony же это UI фреймворк, который всего-лишь позволяет вам быстро организовать UI к вашему приложению (HTTP API или CLI скрипты это только UI приложения) и потому как именно вы будете организовывать архитектуру приложения - это чисто ваша забота. Симфони вам предоставляет только контейнер зависимостей что бы организовать сервисный слой удобненько.

MVC это бесполезные три буквы которые не говорят ровным счетом ничего о том как у вас чего организуется. MVA уже лучше и это именно то что использует подавляющее большиинство на бэкэнде последние лет 10 (в том числе и RoR), но концепция та же - разделение логики представления данных от логики обработки этих данных.

Тогда как поступить с этим? Есть компонент форм для валидации данных и заполнения полей авторизации-регистрации, есть ORM а как мне связать и валидацию и записи через ORM в объект User допустим.


Вам как правильно сделать или как удобно? Как удобно зависит от вас. Вы можете и писать из форм прямо в сущности анемичные и т.д. и еще как хотите. Но по сути флоу должен быть примерно таким:

компонент форм пишет данные в DTO (тупые контейнеры данных). DTO идут в сервисный слой где данные мэпятся на сущность. Сущности (у нас же это пропел)... по правилоному за их сохранноть должны отвечать репозитории, а внутри уже что угодно используйте, но раз уж у нас active record то все что мы можем тут сделать - просто вызвать save в сервисах либо страдать (доктрина в этом плане намного удобнее но у нее есть свои проблемы, а так же она сложная).

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

Так же рекомендую почитать вот эту штуку: The Twelve Factors
Ответ написан
Комментировать
LightAir
@LightAir
LA
Добавляете необходимые директории, к примеру models, classes и прочее, добавляете их в composer.json (если нужно), всё. Можно использовать. По шаблонизатору вариантов мало, либо как выше рекомендовали twig, либо писать свой, либо выдёргивать из существующих фреймворков, к примеру blade из laravel (он по моему даже где то выдернутый есть в composer)
Ответ написан
Ваш ответ на вопрос

Войдите, чтобы написать ответ

Войти через центр авторизации
Похожие вопросы