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

## Security Configuration
security:
    providers:
        main:
            entity: { class: BlogBundle:User, property: id_vk }

Если все приложение можно без проблем покрыть юнит тестами, если у вас тонкие контроллеры и довольно тонкие сервисы и жирные модели, если вы соблюдаете принципы SOLID и т.д... то у вас выходит код который очень легко поддерживать и расширять. Для проектов посложнее есть всякие там DDD, CQRS, есть гексагональная архитектура...

Короче все сводится к такому параметру как maintainability.

https://github.com/phptodayorg/php-must-watch#arch...

updated
если интересно, есть пример "хорошей" архитектуры (ну или основы для нее), ну или как минимум интересной:
https://github.com/qandidate-labs/broadway

Конечно этот пример не подходит для всех предметных областей, но как один из вариантов "посмотреть как люди делают" - как по мне неплохо.

Попробуйте {% if items[myKey] is defined %}

мне кажется у вас немного неправильный подход. не с того конца подходите. ну т.e вы хотите забивать гвозди только потому, что у вас классный молоток. а нужно наоборот, сначала понять, что вы хотите забивать гвозди, а потом уже выбирать молоток для этого дела.

т.е сначала решите, что хотите делать, а потом уже выбирайте инструмент для этого.

Никак. Да и нет в этом никакой надобности.
В сущности страницы добавляется поле - дополнительный уникальный идентификатор (slug зовется буржуями).
В запросе приходит именно этот параметр, и именно по нему вы и ищите в базе.
Вполне себе годное решение.

У меня есть действующая доменная почта для гугла и яндекса. Если кратко:
Google Apps — Яндекс
Платно — бесплатно
Фильтры плохи — хорошие
Скорость загрузки низкая — высокая
Возможность пересылать несколько писем отсутсвует — присутсвует
Удобство гугл аккаунта как единственного аккаунта — нет такой опции
Интерграция с гугл диском и гугл докуементами есть — жалкое подобие в виде яндекс диска
Синхоронизация контактов с телефоном отличная — через жопу
Интерфейс ногу сломаешь — отличный
Встроенный календарь отличный — говно
Возможность встраивать приложение для почты (например плагины для систем управления проектами) прямо в веб-морду gmail — нет таких опций (насколько мне известно).
Возможность отправлять письма с задержкой с помощью сторонних платных приложений — бесплатная встроенная возможность.
Возможность создавать любое количество псевдонимов для почты — можно использовать в качестве псевдонима формат типа <номертелефона>yandex.ru
Приятный интерфейс написания нескольких писем без закрытия основного веб-интерфейса — нет такого интерфейса.
Нет уведомления получателя по СМС — есть такое уведомление.

Функциональность Gmail огромна, но во многих местах реализована не шибко юзерфрендли.

Используйте классы, если вы не видите преимуществ использования структур в вашем коде.
Не уверен, что использование структуры со строкой внутри в листе быстрее использования аналогичного класса. Особенно по сравнению со временем доступа к СУБД.
Подробнее про структуры в MSDN
Структуры можно использовать:
1. Если у вас связь с неуправляемым кодом, где ожидается подобная структура.
2. Если вам критично использование value-типов.
При этом нужно не забывать об особенностях их использования, например, что при присваивании или передачи в функцию структура копируется. Наверняка можно написать пример, где из-за этого производительность работы с большой структурой будет ниже, чем с классом.

вы должны получить не процент (именно незначительный прирост если он вообще будет, в чем я лично сомневаюсь) от производительности а удобства при разработке и поддержке приложения.

Что нужно знать ?
Как минимум 4 темы на первой странице

Договор (с владельцем сайта) на разработку, вестимо

Пример #4 Создание объекта для каждой строки

<?php
class fruit {
    public $name;
    public $colour;
}

$sth = $dbh->prepare("SELECT name, colour FROM fruit");
$sth->execute();

$result = $sth->fetchAll(PDO::FETCH_CLASS, "fruit");
var_dump($result);
?>

upd:

Вот в этом то и проблема. Я пытаюсь скрыть внутри класса всё взаимодействие с БД. А у вашем варианте это не так.

Тогда надо наследовать от чего общего и ложить примерно такую логику (не тестировал, может не работать, но логика такая):

abstract class modelDB
    {
    public static function find()
        {
        $sth = $dbh->prepare("SELECT * FROM `". get_called_class() ."`");
        $sth->execute();

        return $sth->fetchAll(PDO::FETCH_CLASS, get_called_class());
        }
    }

class fruit extends modelDB {
    public $name;
    public $colour;
}

$result = fruit::find();

stdClass является итератором, т.е. ты можешь пробежаться по его свойствам с помощью foreach. Проверить наличие свойства у нужно объекта можно используя property_exists();
Например у тебя получился класс $classFromPDO:

$fooObj = new FooClass();
foreach($classFromPDO as $name => $value){
    if(property_exists($fooObj,$name)){
        $fooObj->{$name} = $value;
    }
}

Примерно как-то так. Кстати, тут не важно, что у тебя в $classFromPDO объект или ассоциативный массив

1)Не поздно.
2)На самом деле вообще не важно, главное начать.
3)Многие сейчас начинают с языка python так он прост и популярен.

Я рекомендую сайт informatics.mccme.ru
Есть например курс по питону: informatics.mccme.ru/course/view.php?id=156
И что важно, можно решать задачки и сдавать их в тестирующую систему, вам будут отвечать правильно ли она решена.

P.S. Вам дофига чего посоветуют, и на самом деле не важно что вы выберите. Успехов вам.

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

Я вообще последнее время стараюсь держать весь код проекта вне бандлов. То есть таких вещей как CoreBundle или MainBundle или AppBundle стараюсь избегать. Во всяком случае пока не жалею. А если я вижу что какой-то код можно реюзать - то можно вынести это дело в бандл.