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

Question

[Alexander]

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

Решил в целях обучения написать простое веб приложение для регистрации и авторизации пользователей.
Задача - поработать со сторонними библиотеками и не использовать фреймворки (сам пишу на 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 допустим.
Как сделать правильно с точки зрения логики?

Также вопрос по шаблонизатору, что порекомендуете?
Думаю что для авторизации и аутентификации также использовать соответсвующие компоненты, или уже перебор?

Answer 1

[Борис Беньковский]

Если уж, вы так хотите разобраться в построении своих велосипедов, а тем более, велосипед конструкторов (вы ж собираетесь юзать библиотеки), попробуйте Silex. Это микрофреймворк, у которого есть только httpkernel, router, Container. Написано это в 2-х файлах, чтоли ))) так что, если разберетесь как там что реализовано, будет крупнейший опыт.
А любое подключение библиотеки Symfony , через свой ServiceProvider ( не готовый!) превратиться в прекрасные вечера проведенные в дебрях кода этих самых библиотек :).
PS. Все описанное выше пробовал сам лично - результат огонь

Comments

[Alexander]

Silex все же микро, но фрейм.. по условиям задачи пользоваться готовым хоть и минимальным фреймом нельзя :-)

[Борис Беньковский]

У нас с Вами вышла ситуация, как у заказчика и исполнителя. Приходит испольнитель, и говорит "Хочу, чтобы ты мне напилил вот такую кнопку, чтобы она шла в Бекенд, потом в БД, потом.... и в итоге выдовала квадрат числа" - а девелопер ему в ответ "Может просто
$('#button').click(function(){
$('#output').value = $('#input').value ^ 2;
});
?".
В нашей ситуации, я вижу, что все-таки вы хотите построить свой фреймворк, поподключать туда кучу либ, и самое, главное, понять как все это работает. Silex, или другой микрофреймворк, как налгядное пособие, или как основа, подойдет как нельзя лучше

[Alexander]

Борис Беньковский: понял вас, посмотрю Silex тогда для начала.. Задача сделать просто приложение, не обязательно чтоб он был универсален как фреймворки. Спасибо за наводку.

[Сергей Протько]

Alexander: фреймворки как бы и не универсальны, они решают общие задачи, а не все задачи. Ну это так, лирика.

Answer 2

[Кирилл Арутюнов]

По поводу шаблонизатора - можно Twig попробовать. Он от разработчиков Симфони.

Comments

[Alexander]

Ага спасибо тоже о нем думал. А что скажите о том как лучше организовать связь сущность + формы + ORM?

[Кирилл Арутюнов]

Alexander: вот тут не подскажу. В одном из проектов использовал Propel - он генерировал модели (BaseModel и Model, который наследуется от BaseModel). В BaseModel как раз описывались все правила валидации и сама функция validate().
Проект, кстати, работал на Silex (микрофреймворк на компонента Симфони).

[Сергей Протько]

Alexander: в идеале - ORM - сущности - DTO - формы. В идеале - Doctrine2

Answer 3

[Алексей Павлов]

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 :)

Comments

[Alexander]

Спасибо за ответ! Ну все компоненты гнать не хочется, хочется просто построить мини приложение так чисто чтоб поковыряться в сторонних либах. Поэтому и взял только HttpKernel,Forms,ORM,Security,ClassLoader да шаблонизатор. А модель наверное просто сделаю как класс и будут inject-ить объект орма чтоб можно было внутри реализовать нужные методы.

[Алексей Павлов]

Alexander: Компонент ClassLoader не обязателен, композер справится не хуже, особенно если использовать флаг -o. Разница в том, что ClassLoader умеет писать классмап в кэш ApcCache.

И всё-таки, если уж берёте ORM, то возьмите Doctrine2, а не Propel. "Попробовав раз, ем и сейчас" (с)

[Alexander]

Алексей Павлов: По ClassLoader понял. Если возьму доктрину то получится что и прослойки писать не нужно будет? Т.е я сам в классе User сделаю нужные методы и скрою поля таблицы БД. И тогда класс будет и как сущность и подключена к доктрине (т.е работать с бд можно будет)?

[Алексей Павлов]

Alexander: да, верно. Доктрина берёт на себя всю "грязную" работу с БД. От вас только сделать классы моделей и указать метаданные полей (проще всего прямо в аннотации класса сущности).

/** @Entity */
class Person {
    /** 
     * @Id 
     * @Column(type="integer") 
     * @GeneratedValue 
     */
    private $id;

    /** 
     * @Column(type="string") 
     */
    private $firstname;

    /** 
     * @Column(type="string") 
     */
    private $lastname;

    public function getId() {
        return $this->id;
    }

    public function getFirstname() {
        return $this->firstname;
    }

    public function setFirstname($firstname) {
        $this->firstname = $firstname;
    }

    public function getLastname() {
        return $this->lastname;
    }

    public function setLastname($lastname ) {
        $this->lastname = $lastname ;
    }

    public function getFullname() {
        return $this->firstname . ' ' . $this->lastname;
    }
}

А Twig сам умеет понимать геттеры и сеттеры, и там достаточно написать {{ person.fullname }}

[Алексей Павлов]

Alexander: кстати, тот же PhpStorm умеет генерить геттеры с сеттерами, то есть, для вас останется ещё меньше работы.

Answer 4

[Сергей Протько]

Разделить приложение по паттерну 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

Answer 5

[Light Air]

Добавляете необходимые директории, к примеру models, classes и прочее, добавляете их в composer.json (если нужно), всё. Можно использовать. По шаблонизатору вариантов мало, либо как выше рекомендовали twig, либо писать свой, либо выдёргивать из существующих фреймворков, к примеру blade из laravel (он по моему даже где то выдернутый есть в composer)

Comments

[Alexander]

Директории, namespace добавлю.. главная проблема как построить связку с формой-сущностью-и бд по ОРМ

[Light Air]

Alexander: Можно реализовать свой абстрактный слой для этих целей, если конечно я правильно понял вопрос. Не знаю на счёт Propel, так получилось, что по нему я даже доки не смотрел, но к примеру в doctrine он (абстрактный слой) реализован, dbal называется.

[Alexander]

Light Air: мне просто хочется сделать типа такого: $user->setOrm = $userPropel; // т.е подгрузить объект орма в модель User и потом уже внутри реализовать validate(), для валидации и потом методы авторизации - регистрации.. не знаю вот только насколько решение хорошее