Извините, но комментарии к тому посту говорят об обратном: и случаи не единичны, и разбираетесь вы не оперативно. Лично я пока больше верю отзывам хабровчан, нежели Вам. Ничего личного.
Молодцы, работаете в нужном направлении. Но после таких постов habrahabr.ru/post/223149/ доверять бизнес-почту как-то страшно, вдруг мне выгодное предложение прислать захотят, а Ваш анти-спам его зареджектит и слова не скажет?
На самом деле он был показан на конференции BUILD 2014 в качестве вектора для дальнейшего развития Windows. Дальше просто по новостям без сути разошелся.
Кстати, к слову сказать, Ваш код сработает и без @ParamConverter, по крайней мере в 2.4 версии точно, но по моему и раньше было. Т.е. когда вы используете один входящий параметр со строгой типизацией, этот тип является сущностью доктрины и в роуте присутствует явно названный id, то такое приведение выполняется по умолчанию. Смысл использовать @ParamConverter есть, когда у вас более одного параметра или же приведение используется не по идентификатору например, ну и т.д.
Я конечно не в курсе на счет yml, т.к. проектов под рукой на которых посмотреть можно было бы нет, а искусственно делать пока нет времени, но вот то что аннотации кэшируются по умолчанию, это 100%. Вот Вам пример, в каком виде этот кэш лежит .
Более того, если вы измените аннотации и продолжите использовать prod окружение без сброса кэша, то эти изменения тоже никак не отразятся на работе приложения, что еще раз подтверждает их закэшированность. Кстати, тот же принцип работает и на config.yml например, попробуйте сменить реквизиты доступа к БД в prod окружении — приложение продолжит работать по старому подключению до сброса кэша. А вот в dev окружении да, по умолчанию ничего не кэшируется — ни аннотации, ни конфиги. Но Вы не запускаете большие проекты в работу на dev окружении?
Простите, а в чем разница для боевой среды? Что в случае использования yml или xml, что в случае использования аннотаций, так или иначе в Symfony информация об этом кэшируется, т.е. непосредственное чтение этой информации происходит всего лишь при первом запуске приложения, а дальше она себе спокойненько валяется в кэше в одном и том же виде. Это конечно если рассуждать о скорости работы, а остальные причины, на мой взгляд, чисто идеологические.
asozd2.duma.gov.ru/main.nsf/(Spravka)?OpenAgent&RN=428884-6&11 вот тут вся информация о данном законопроекте, в том числе хронология и проект. Речь там идет не о владельце, а о «организаторе распространения информации и (или) обмена данными между пользователями в сети «Интернет»», что они в это понятие вкладывают, и что в их понимании «распространение информации» я пока так и не понял.
Всегда гордился, что учился в этой школе. А теперь еще больше! Молодцы! Представляю, каких трудов стоит протолкнуть такой проект сквозь все сложности организации информационных систем в муниципальных учреждениях провинциальных городков.
А от старости и болезней людей гибнет еще больше чем от ДТП. Так давайте и на эту область забьем, не будем выносить никаких уроков из своей деятельности вообще!
Из любой катастрофы, в которой гибнут люди, должны быть сделаны выводы и предприняты меры по предотвращению подобного в будущем. И не важно какого типа катастрофа — космическая, авиа или банальное ДТП. Кстати, правила дорожного движения тоже кровью писаны…
P.S. автору спасибо за очень хорошую познавательную статью
Минуточку, я советовал лишь закрывать контекст, после выборки данных, но не призывал отказываться от ViewModel — это разве плохой совет?:) С Вашим комментарием абсолютно согласен, это как раз хороший аргумент в сторону использования ViewModel ну и data object в целом. По хорошему: открыли контекст, выбрали необходимые сущности, из них сформировали нужные модели для представления, закрыли контекст ну и дальше собственно в представление.
Просто я согласен с lair, что аргументы Revkov несколько неполные, проблемы описанные в пунктах 1,3,4 можно решить и без ViewModel, особенно в небольших проектах, но конечно это не является хорошей практикой, а вот из того, почему не является, вытекает почему стоит таки использовать отдельные объекты для передачи в представления. Как то так.
Кстати, касаемо 4 пункта: если контекст опять же будет закрыт, то собственно негде будет вызывать SaveChanges(), а если открыть его заново, то выбранные сущности к нему присоединены уже не будут. Так что ничего страшного не произойдет. Вообщем, закрывайте контекст после выборки, это устранит проблемы сразу 3-х описанных Вами пунктов :)
1. Не будет, если закрывать контекст. Выбрали данные в блоке using и все, сущности сформированы, находятся в оперативной памяти, соединение закрыто.
2. Вот это уже весомый аргумент, не всегда те данные, которые будут отображаться в представлении один в один по структуре совпадают с БД
3. Совсем не ускоряет. Что бы сформировать модель для представления Вам так же ее надо выбрать нужные данные из БД. И сущности EF так же будут находится в оперативной памяти, если Вы их корректно извлечете из БД, закрыв после соединение (см. п.1)
4. В целом согласен, но не припомню ни разу, что бы приходилось изменять как модель для представления, так и сущность, что бы показать ее в представлении. Сформировали, а дальше просто вывод нужных данных.
Я наверное сейчас минусов словлю за пятничную тупизну, но все же… Ребят, ну давайте хотя бы небольшую вводную к статье с пояснением, что это за iBeacon. Мне, как человеку далекому от Apple, весьма сложно въехать в смысл статьи и тем более данной технологии. Ну хотя бы ссылочку на описание. Да, я знаю, что есть google и прочие поисковые сервисы, и что данную информацию при желании я могу быстро найти, но все же хочется читать все в одном едином блоке, не прыгая по вкладкам и сайтам.
А чем Вам этот вариант не нравится? У вас же результат работы контроллера должен показываться в определенном месте в шаблоне, значит шаблон и должен его подключить в то место, в которое нужно. По моему все вполне логично.
Для полнейшей гармонии не хватает только обернуть подключение контроллера в блок, что бы в случае чего можно было в любом месте сайта этот блок переопределить или дополнить.
Более того, если вы измените аннотации и продолжите использовать prod окружение без сброса кэша, то эти изменения тоже никак не отразятся на работе приложения, что еще раз подтверждает их закэшированность. Кстати, тот же принцип работает и на config.yml например, попробуйте сменить реквизиты доступа к БД в prod окружении — приложение продолжит работать по старому подключению до сброса кэша. А вот в dev окружении да, по умолчанию ничего не кэшируется — ни аннотации, ни конфиги. Но Вы не запускаете большие проекты в работу на dev окружении?
Из любой катастрофы, в которой гибнут люди, должны быть сделаны выводы и предприняты меры по предотвращению подобного в будущем. И не важно какого типа катастрофа — космическая, авиа или банальное ДТП. Кстати, правила дорожного движения тоже кровью писаны…
P.S. автору спасибо за очень хорошую познавательную статью
Просто я согласен с lair, что аргументы Revkov несколько неполные, проблемы описанные в пунктах 1,3,4 можно решить и без ViewModel, особенно в небольших проектах, но конечно это не является хорошей практикой, а вот из того, почему не является, вытекает почему стоит таки использовать отдельные объекты для передачи в представления. Как то так.
2. Вот это уже весомый аргумент, не всегда те данные, которые будут отображаться в представлении один в один по структуре совпадают с БД
3. Совсем не ускоряет. Что бы сформировать модель для представления Вам так же ее надо выбрать нужные данные из БД. И сущности EF так же будут находится в оперативной памяти, если Вы их корректно извлечете из БД, закрыв после соединение (см. п.1)
4. В целом согласен, но не припомню ни разу, что бы приходилось изменять как модель для представления, так и сущность, что бы показать ее в представлении. Сформировали, а дальше просто вывод нужных данных.
Для полнейшей гармонии не хватает только обернуть подключение контроллера в блок, что бы в случае чего можно было в любом месте сайта этот блок переопределить или дополнить.