ну вот я про то, как узнать, что он именно User, а не какой-нибудь doctrine.orm_default.bla-bla-bla
Вариант с именем класса сервиса мне показался элегантным ) Ну и именовать надо конечно по общему правилу.
Может быть не хватает чуть более подробного введения и описания общего алгоритма, по которому создаются сервисы. «АФ — это последняя попытка СМ создать запрашиваемый сервис.» Вот на этой фразе закрадывается мысль, что наверное Service Locator проходит по всем сервисам в каком-то определенном порядке. Но об этом вы наверное собирались написать во второй части.
А еще во второй части можно было написать, для чего вообще СМ нужен, про IoC, про вынесение абстракции «наверх» и удобство тестирования, ну и про минусы, разумеется, т.к. Service Locator активно критикуют и в ZF3 вроде намечены какие-то изменения на этот счет.
Тоже хотел заметить, что Service Locator лишь один из паттернов, решающих задачу DI, есть в ZF2 и другой вариант, про который вы упомянули. Но комментатор видимо имел в виду, что те сервисы, которые есть в Symfony более легковесны: symfony.com/doc/current/components/dependency_injection/configurators.html
При старте любого PHP-фреймворка вообще происходит каждый раз много всего лишнего, чего не хотелось бы делать при каждом запросе. И уж проверка incanceof едва ли окажется узким местом приложения. На эту тему была тут статья «PHP должен умирать» (кто-то дал неверный перевод «умереть»), в том смысле, что при каждом запросе весь цикл инициализации приходится проходить заново. Кстати, была интересная статья с экспериментом, решающим эту проблему: habrahabr.ru/post/220393/
Многие все же выбирают удобство и скорость разработки, а оптимизацией занимаются, когда того требует ситуация.
Еще вопрос: Как решить вопрос с автодополнеием имен сервисов при обращении к ним? Даже в относительно небольшом проекте сервисов набирается не один десяток, держать каждый из них в голове не получается, приходится каждый раз сверяться с конфигом.
Спасибо, полезно. Отдельно порадовало упоминанию нюанса с замыканиями и кэшированием. Первый раз с этим сталкиваешься, когда уже все написано и дошло дело до оптимизации. И тут начинается утомительный процесс вынесения всех замыканий в отдельные классы.
Правда для новичков, мне кажется, вы погорячились, слишком многое остается за скобками :)
Вопрос — инициализаторы вызываются для всех сервисов?
Не очень понял про искусственные связи. Если мне нужен именно справочник характеристик, чтобы в них был порядок, и каждый контент-менеджер не наполнял каталог, как ему вздумается, то связи там довольно очевидны. Само понятия справочника по своей природе «реляционно». Или вы хотите сказать, что не зачем использовать nosql там, где ему не место? В частности для подобного каталога.
Кстати, а как вы решили вопрос с числовыми характеристиками, по которым мало вариантов? Ну например, слоты расширения в материнской плате. Их удобно задавать и хранить просто как число, но если вариантов мало, то в форме выводить не слайдер, а чекбоксы. Я пока налету конвертирую число в список значений, получая из базы все уникальные варианты. Похоже это тоже сильно сказывается на производительности, зато можно одной галочкой в настройках переключать вариант отображения по каждой характеристике.
Изначально я задал разделение по типам потому что полагал, что хранить число в строке и вести по ним поиск — кощунственно, потому создаем 3 таблицы.
Глянул вашу статью. Ну так у меня поля все числовые, я строки не храню. Есть столбец value для boolean и numeric, есть столбец variant_id для select/multiselect (multiselect использует еще и value=0/1). Строковые характеристики отсутствуют как класс, нефиг — для порядку )) Правда value у меня float, наверное нехорошо…
Select/Multiselect естественно тоже через справочники. А вот атрибуты по типам не раскидывал. А что это даст? Раз по каждому типу все равно идет отдельный запрос, то лучше вынести их в отдельные таблицы, чтобы поиск шел по меньшему кол-ву записей?
Ну и еще у меня обычный VDS за 1000р. в месяц, может в этом дело? :)
Я вот все присматриваюсь к MongoDb для решения такой же задачи, и мучает меня вопрос. Из-за чего там достигается такая скорость поиска? Ведь принципиально новых способов повышения производительности в программировании никто не придумал — есть только два способа — платить либо ростом вычислительной мощности (распараллеливание), либо ростом хранилища (кэш). Правильно ли я понимаю, что по сути nosql по сравнения с sql — это своего рода кэш за счет денормализации, т.е. вместо лишних джоинов у нас все связанные данные уже есть в документе? Отсюда напрашивается другой вопрос — а как быть с изменениями данных? Если база денормализована, то при изменении связанных данных я должен пройтись по всем документам, где эти данные задействованы?
Тоже работает подобное на mysql, правда скорость на порядок меньше и база не очень большая. 0.05 с у вас случайно не по кэшированным запросам? По ним и у меня все быстро работает. Но проблема в том, что на таком кол-во вариантов кэш бессмысленен — слишком много комбинаций параметров.
Как вы храните характеристики в базе? У меня по сути EAV, правда слегка измененный вариант. У меня есть общий справочник характеристик, который к товарам никак не привязан. Непосредственно к товарам привязаны значения характеристик, а по значениям уже сами характеристики. У меня 4 типа характеристик (numeric, boolean, select, multiselect), по каждому свой запрос приходится делать. Надо наверное в отдельном посте это расписать :)
Какая разница, где в квартире вы сидите, в Киеве или в Самаре?
Везде своё проплаченное ТВ,
Правда на Украине правят балом любители демократии — Американцы. Со всеми вытекающими.
Вот казалось бы, правдивый комментарий, ведь пропаганда работает с обоих сторон. А нет, заминусовали и слили карму человеку. И так по всему топику. Посмотрите на страну тех, кого заминусовали и тех кто минусует. Если одних заминусовали, а других наоборот — что это значит? Что первые неправы, а вторые правы? Нет, это всего лишь значит что вторые объединились и более активны. Это опять же к вопросы о пропаганде. Включайте голову, господа. Соотношение правдивой/ложной информации с обоих сторон в среднем одинаково. В такой ситуации судить надо по косвенным признакам, в первую очередь исходить из принципа кому выгодно. А дальше каждый видит, что хочет в зависимости от своей непредвзятости и аналитических способностей.
Я не утверждаю, что документации не хватает (сам работаю с ZF2). Простейшие вещи описаны в официальной документации, сложные решения довольно легко гуглятся. Просто уже довольно длительное время не попадается новых материалов по ZF, хотя по Симфони в т.ч. в дайджестах регулярные обновления. Я все-таки эту активность связываю с недавним получением доп. финансирования для Симфони. Разработчики ZF2 сейчас похоже переключились на Apigility.
Впрочем, оба фреймворка довольно неплохо сосуществуют вместе и правильно написанные модули легко используются независимо от фреймворка либо сразу, либо через несложные адаптеры.
Вариант с именем класса сервиса мне показался элегантным ) Ну и именовать надо конечно по общему правилу.
А еще во второй части можно было написать, для чего вообще СМ нужен, про IoC, про вынесение абстракции «наверх» и удобство тестирования, ну и про минусы, разумеется, т.к. Service Locator активно критикуют и в ZF3 вроде намечены какие-то изменения на этот счет.
Многие все же выбирают удобство и скорость разработки, а оптимизацией занимаются, когда того требует ситуация.
Правда для новичков, мне кажется, вы погорячились, слишком многое остается за скобками :)
Вопрос — инициализаторы вызываются для всех сервисов?
Ну и еще у меня обычный VDS за 1000р. в месяц, может в этом дело? :)
Как вы храните характеристики в базе? У меня по сути EAV, правда слегка измененный вариант. У меня есть общий справочник характеристик, который к товарам никак не привязан. Непосредственно к товарам привязаны значения характеристик, а по значениям уже сами характеристики. У меня 4 типа характеристик (numeric, boolean, select, multiselect), по каждому свой запрос приходится делать. Надо наверное в отдельном посте это расписать :)
Вот казалось бы, правдивый комментарий, ведь пропаганда работает с обоих сторон. А нет, заминусовали и слили карму человеку. И так по всему топику. Посмотрите на страну тех, кого заминусовали и тех кто минусует. Если одних заминусовали, а других наоборот — что это значит? Что первые неправы, а вторые правы? Нет, это всего лишь значит что вторые объединились и более активны. Это опять же к вопросы о пропаганде. Включайте голову, господа. Соотношение правдивой/ложной информации с обоих сторон в среднем одинаково. В такой ситуации судить надо по косвенным признакам, в первую очередь исходить из принципа кому выгодно. А дальше каждый видит, что хочет в зависимости от своей непредвзятости и аналитических способностей.
Впрочем, оба фреймворка довольно неплохо сосуществуют вместе и правильно написанные модули легко используются независимо от фреймворка либо сразу, либо через несложные адаптеры.