Комментарии 11
Даже не знаю, красиво ли, например, «ограничивать статью до 250 символов» в самом коде, а не в шаблоне дизайна.
Еще у меня вопросик, не по конкретно вашей схеме, а вообще.
Если у нас используется объектная модель, где есть например класс NewsItem, который в конструкторе выбирает из базы себя по id, и есть класс NewsLine, который содержит несколько NewsItem. С точки зрения ООП красиво чтоб каждый NewsItem сам себя выбрал из базы. Но тогда же будет много запросов к базе, вместо одного, которым можно было бы выбрать сразу все нужные новости.
Вопрос в том, как обычно это реализовано — как классы взаимодействуют с базой? Просто в моем движке магазина не бывает более 10 запросов на странице, а у других я видел и сотни. Как же так? Стоит ли жертвовать скоростью ради… а ради чего, собственно у других движков столько запросов?
Еще у меня вопросик, не по конкретно вашей схеме, а вообще.
Если у нас используется объектная модель, где есть например класс NewsItem, который в конструкторе выбирает из базы себя по id, и есть класс NewsLine, который содержит несколько NewsItem. С точки зрения ООП красиво чтоб каждый NewsItem сам себя выбрал из базы. Но тогда же будет много запросов к базе, вместо одного, которым можно было бы выбрать сразу все нужные новости.
Вопрос в том, как обычно это реализовано — как классы взаимодействуют с базой? Просто в моем движке магазина не бывает более 10 запросов на странице, а у других я видел и сотни. Как же так? Стоит ли жертвовать скоростью ради… а ради чего, собственно у других движков столько запросов?
«ограничивать статью» наверное плохой пример, слишком простой… чаще всего это используется, если надо, например, вывести список товаров (релузьтаты поиска). В этом случае не нужно «выдавать» шаблонизатору всю карточку товара целиком (все поля) — при 100 результатах на странице может быть переполнение памяти.
про 10 запросов… да, именно так — на странице может быть больше сотни запросов. Чаще всего разница в скорости небольшая, но если требуется, то оптимизация не больно хитрая — очень неплохо спасает memcached и тонкая настройка MySQL сервера.
Ради чего?.. Ради качества кода. Код получается очень гибкийи понятный.
про 10 запросов… да, именно так — на странице может быть больше сотни запросов. Чаще всего разница в скорости небольшая, но если требуется, то оптимизация не больно хитрая — очень неплохо спасает memcached и тонкая настройка MySQL сервера.
Ради чего?.. Ради качества кода. Код получается очень гибкийи понятный.
вы не с той стороны подходите к проблеме. список товаров в каталоге, в результате поиска или списке новых товаров — одинаковые или очень похожи. карточка товара — это уже НЕ СПИСОК товаров а экземпляр. Для него правильнее сделать отдельный запрос, а не пытаться получить его через регресс интерфейса получения списков. ведь очевидно что ваш подход плодит кучу лишних запросов к БД и лишает гибкости кстати.
поэтому я обычно делаю один метод который генерирует запрос, учитывая структуру таблицы товаров и специфику вывода в шаблон, и далее через общие интерфейсы генерится нужный вид отображения… тогда можно выбирать ОДНИм запросом, который сразу вытаскивает все что нужно, для данной сущности и контекста использования
поэтому я обычно делаю один метод который генерирует запрос, учитывая структуру таблицы товаров и специфику вывода в шаблон, и далее через общие интерфейсы генерится нужный вид отображения… тогда можно выбирать ОДНИм запросом, который сразу вытаскивает все что нужно, для данной сущности и контекста использования
Возможна другая ситуация, другой случай — признаки паттерна Стратегия.
«Управляющий скрипт (допустим, конструктор страницы) «знает» в каком виде NewsPost::Data() должен вернуть данные, однако он не может напрямую взаимодействовать с объектами класса NewsPost, потому как это «забота» класса News. Следовательно, все, что может скрипт, это» — инстанцировать нужную стратегию.
Имхо, Команда для приведенного случая тяжеловата — у нас простая, по разному отображаемая, коллекция.
Еще несколько смущает «NewsPost» и «NewsPostBody» — это новость и ее текст? Стоит ли делать такую подробную иерархию? Может быть из-за этого понадобился паттерн поведения?
«Управляющий скрипт (допустим, конструктор страницы) «знает» в каком виде NewsPost::Data() должен вернуть данные, однако он не может напрямую взаимодействовать с объектами класса NewsPost, потому как это «забота» класса News. Следовательно, все, что может скрипт, это» — инстанцировать нужную стратегию.
Имхо, Команда для приведенного случая тяжеловата — у нас простая, по разному отображаемая, коллекция.
Еще несколько смущает «NewsPost» и «NewsPostBody» — это новость и ее текст? Стоит ли делать такую подробную иерархию? Может быть из-за этого понадобился паттерн поведения?
Пример с News — всего лишь пример. Хотел попроще, да видно перестарался.
Один из ключевых моментов сдесь — т.н. контекст, и то что он может быть вложенным, а не сам параметр, поэтому «стратегия» не подходит, по карйней мере «в чистом виде»
т.е. я устанавливаю параметр для «всего, что внутри News cut=true» в одном месте программы, после этого, находясь в контексте «News» у параметра cut будет значение true. Если где-то «дальше» я установлю для этого параметра другое значение в дроугом контексте, допустим «News/NewsPost cut=false» то в «News» он по-прежнему останется «true» а в NewsPost, NewsPostBody будет иметь значение false.
Опять же, более реальный пример с результатами поиска: я не хочу врезультатх поиска полную карточку товара со всеми полями, поэтому устанавливаю «Product/Profile:fieldsetMode=short» когда Profile формирует массив с полями он проверят значение fieldsetMode и соответсвенно возвращает «сокращенный» набор.
короче говоря — это не стратегия. Что-то вроде набора значений в определенном namesapce, который может быть вложенным.
Один из ключевых моментов сдесь — т.н. контекст, и то что он может быть вложенным, а не сам параметр, поэтому «стратегия» не подходит, по карйней мере «в чистом виде»
т.е. я устанавливаю параметр для «всего, что внутри News cut=true» в одном месте программы, после этого, находясь в контексте «News» у параметра cut будет значение true. Если где-то «дальше» я установлю для этого параметра другое значение в дроугом контексте, допустим «News/NewsPost cut=false» то в «News» он по-прежнему останется «true» а в NewsPost, NewsPostBody будет иметь значение false.
Опять же, более реальный пример с результатами поиска: я не хочу врезультатх поиска полную карточку товара со всеми полями, поэтому устанавливаю «Product/Profile:fieldsetMode=short» когда Profile формирует массив с полями он проверят значение fieldsetMode и соответсвенно возвращает «сокращенный» набор.
короче говоря — это не стратегия. Что-то вроде набора значений в определенном namesapce, который может быть вложенным.
честно говоря, я не понял зачем вы так усложнили — простую, по сути, логику формирования списка и экземпляра данных.
и гибкости в вашем решении я не вижу. ведь оно заставляет вас плодить сущности и усложнять структуру классов.
приведите пожалуйста реальный пример, в вашем приложении, когда ваш подход реально чтото упрощает или унифицирует.
и гибкости в вашем решении я не вижу. ведь оно заставляет вас плодить сущности и усложнять структуру классов.
приведите пожалуйста реальный пример, в вашем приложении, когда ваш подход реально чтото упрощает или унифицирует.
решение ничуть не усложняет структуру классов. изменяется лишь метод, ответсвенный за выдачу данных шаблонизатору. логика формирования списка и экземпляра данных у меня не простая, потому что у меня сплошные классы и объекты с хорошей инкапсуляцией, и нужно как-то повлиять на логику определенных методов.
пример кода:
на странице:
…
$this->add( Auctions::getFeatured(), new Parameters('Auction/Vehicle/VehicleProfile:mode=short') );
…
в классе VehicleProfile:
…
$params->useContext('VehicleProfile');
if( $params->get('mode') == 'short') $fieldsParam= new Parameters('Fields:Manufacturer,Model,Year');
$data->add( $this->Data_Fields( $fieldsParam ) );
пример кода:
на странице:
…
$this->add( Auctions::getFeatured(), new Parameters('Auction/Vehicle/VehicleProfile:mode=short') );
…
в классе VehicleProfile:
…
$params->useContext('VehicleProfile');
if( $params->get('mode') == 'short') $fieldsParam= new Parameters('Fields:Manufacturer,Model,Year');
$data->add( $this->Data_Fields( $fieldsParam ) );
а теперь представьте,
что нужно в зависимости от mode join-нить разные таблицы с разными атрибутами товаров например
и в каждой из этих таблиц еще куча условий в Where
незнаю как у вас внутри реализованы Data_Fields и контексты, но думаю что даже тут уже вы столкнетесь с ограничениями. в которые вы сами себя загоняете таким подходом.
imho ваш подход решает достаточно частный случай. и с большой натяжкой можно считать его очень гибким и универсальным
что нужно в зависимости от mode join-нить разные таблицы с разными атрибутами товаров например
и в каждой из этих таблиц еще куча условий в Where
незнаю как у вас внутри реализованы Data_Fields и контексты, но думаю что даже тут уже вы столкнетесь с ограничениями. в которые вы сами себя загоняете таким подходом.
imho ваш подход решает достаточно частный случай. и с большой натяжкой можно считать его очень гибким и универсальным
насколько я понял, вы не используете ООП и инкапсуляцию, так что для вас, несомненно, такой подход будет «не гибким»
>так что для вас, такой подход будет «не гибким
Идея слабо зависит от реализации.
Если решение неуниверсально, то её не спасет ни ООП ни АОП ни чтото другое.
ведь это всего лишь методики программирования, они не делают алгоритм лучше.
конечно, в вашем подходе я вижу рациональное зерно. но у него есть очевидные ограничения.
просто задумайтесь над этим, и может вы поймете как сделать его лучше )
>вы не используете ООП
я раньше тоже строил приложения на основе «многоэтажных» классов и интерфейсов, все это было жутко взаимозависимо, громоздко и ресурсоемко. но мне тогда казалось что это и есть true ООП)
Но, по настоящему стало легко и свободно кодить когда я упростил все что можно, заменил часть объектов массивами, оставшиеся классы сделал максимально независимыми и т.д.
Удивительно, но скорость и удобство разработки даже возросло)
Идея слабо зависит от реализации.
Если решение неуниверсально, то её не спасет ни ООП ни АОП ни чтото другое.
ведь это всего лишь методики программирования, они не делают алгоритм лучше.
конечно, в вашем подходе я вижу рациональное зерно. но у него есть очевидные ограничения.
просто задумайтесь над этим, и может вы поймете как сделать его лучше )
>вы не используете ООП
я раньше тоже строил приложения на основе «многоэтажных» классов и интерфейсов, все это было жутко взаимозависимо, громоздко и ресурсоемко. но мне тогда казалось что это и есть true ООП)
Но, по настоящему стало легко и свободно кодить когда я упростил все что можно, заменил часть объектов массивами, оставшиеся классы сделал максимально независимыми и т.д.
Удивительно, но скорость и удобство разработки даже возросло)
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
PHP: Параметры в контексте