Комментарии 51
хорошее решение, а главное оптимальное, т.к. ранее с каждым новым модулем плодились sql запросы. Для сайтов с маленькой посещаемостью это было неощутимо, а вот для крупных сайтов уже да. Спасибо!
Интересно, каким образом ORM поможет вам сократить количество запросов к БД?
О чем вы говорите? То что вы будете использовать ORM не значит, что у вас станет меньше запросов к базе данных, чем это было раньше. Это зависит от того как вы проектируете свою систему. Так что посещаемость здесь ни причем.
Скажу вам больше, как правила ORM решения несколько тяжелее для базы, чем жесткие запросы в коде. Так как иногда совершает некоторые лишние запросы для получения информации. Например, в .NET при использовании Linq To SQL, чтобы удалить объект его необходимо сначала запросить, то есть получается два запроса SELECT + DELETE вместо одного DELETE.
Скажу вам больше, как правила ORM решения несколько тяжелее для базы, чем жесткие запросы в коде. Так как иногда совершает некоторые лишние запросы для получения информации. Например, в .NET при использовании Linq To SQL, чтобы удалить объект его необходимо сначала запросить, то есть получается два запроса SELECT + DELETE вместо одного DELETE.
Здорово, как понимаю назревает LS 0.5
0.4 вышел весной 2010,
было б здорово ожидать следующую версию к весне 2011,
чтоб не менять традиций :)
0.4 вышел весной 2010,
было б здорово ожидать следующую версию к весне 2011,
чтоб не менять традиций :)
Пользуюсь движком, еще раз спасибо авторам. =)
class ModuleGallery extends ModuleORM {
public function Init() {
parent::Int();
}
}
Во-первых, наверное Parent::Init()?
А во-вторых, никогда не понимал, зачем писать подобные конструкции? Ведь метод родителя и так вызовется, если в текущем классе его нет…
Автор все правильно написал.
Что правильного?
Родительский метод называется init(). По второму поводу надо еще что-то обосновывать? Вы ж __construct() в классе (надеюсь) не пишете, если ничего своего туда не добавляется.
Родительский метод называется init(). По второму поводу надо еще что-то обосновывать? Вы ж __construct() в классе (надеюсь) не пишете, если ничего своего туда не добавляется.
А в случае если в init() реализации класса ModuleGallery надо еще какие-то действия добавить?
хороший вопрос: дело в том, что Init — абстрактный метод, и должен быть прописан у наследников.
возможно, мы откажемся от этого в ближайшее время.
а Init — действительно опечатка, спасибо, исправил
возможно, мы откажемся от этого в ближайшее время.
а Init — действительно опечатка, спасибо, исправил
исходя из кода ModuleORM, метод Init() все же не абстрактный.
Уже поправили выше, что не абстрактный. Да и нет смысла требовать в дочерних объектах его реализации — как правило действия одни и те же.
Еще оффтоп-вопрос по Code Style — почему protected-методы класса пишутся с подчеркиванием (_loadMapperORM()), а свойства (oMapperORM) без подчеркивания? Немного странно выглядит
Еще оффтоп-вопрос по Code Style — почему protected-методы класса пишутся с подчеркиванием (_loadMapperORM()), а свойства (oMapperORM) без подчеркивания? Немного странно выглядит
Организация релейшенов похожа на Yii'вскую, удобно.
А почему Вы выбрали именно паттерн Active Record, а не Data Mapper?
А почему вы не внедрили в LiveStreet существующую ORM, например Doctrine?
Причём Doctrine 2, реализующий Data Mapper
ну я же просил :) вы статью не до конца дочитали? )
так же можно спросить — почему LS мы не на ZF написали… ;)
так же можно спросить — почему LS мы не на ZF написали… ;)
то есть не мы, а ort, разработчик ядра )
$oAlbum = LS::Ent('Gallery_Album');
статическая связность — это плохо. особенно плохо, если захотите использовать юнит-тесты
статическая связность — это плохо. особенно плохо, если захотите использовать юнит-тесты
Иллюстрация где ORM в облаке на водит на мысль, что сейчас очень модно где только можно упоминать облака и облачную архитектуру.
Я вижу пару значительных ошибок:
1. Модель extends Че-то-еще — ребята из Доктрины, например, давно уже поняли что это приводит к жопе с ручками, и перестали так делать.
2. $model->save(); а эта ошибка вообще непростительна — это вопиющий ппц.
1. Модель extends Че-то-еще — ребята из Доктрины, например, давно уже поняли что это приводит к жопе с ручками, и перестали так делать.
2. $model->save(); а эта ошибка вообще непростительна — это вопиющий ппц.
ага
1. наследование бензина от машины или наоброт, думаю смысл ясен
2. результат п.1 а в дополнение еще и знание моделью того что она умеет сохраняться, удаляться еще «что-то с собой делаться»
1. наследование бензина от машины или наоброт, думаю смысл ясен
2. результат п.1 а в дополнение еще и знание моделью того что она умеет сохраняться, удаляться еще «что-то с собой делаться»
начну с
2) у нас сохраняется не модель, а сущность, которая является частью модуля.
Фактически
это алиас для
Вы говорите что-то слишком неожиданное, вы хорошо знакомы с сущностью паттерна ActiveRecord?
1) это вам вообще к разработчикам PHP и идеологам ООП.
2) у нас сохраняется не модель, а сущность, которая является частью модуля.
Фактически
$oSample->Save();это алиас для
LS::E()=>Example_SaveSample($oSample);Вы говорите что-то слишком неожиданное, вы хорошо знакомы с сущностью паттерна ActiveRecord?
1) это вам вообще к разработчикам PHP и идеологам ООП.
модель или сущность — как хотите, смысл один, что вы например будете делать если надо будет сохранять вашу «сущность или модель» в несколько разных мест? Где вы разместите PubSub чтобы например обновлять дельта индекс сфинкса при сохранении статьи? и много еще вопросов.
Как правило сохранение «модели или сущности» тянет за собой, кроме мапинга в базу, целый комплекс мероприятий.
Про «алиас» — этот алиас у вас реализован ведь в EntityOrm?
Про неожиданность моих высказываний и про ваш отсыл к разработчикам пхп скажу вот что:
Model_Name_Db::Save($model) — а лучше Model_Name_Service::Save($model);
Как правило сохранение «модели или сущности» тянет за собой, кроме мапинга в базу, целый комплекс мероприятий.
Про «алиас» — этот алиас у вас реализован ведь в EntityOrm?
Про неожиданность моих высказываний и про ваш отсыл к разработчикам пхп скажу вот что:
Model_Name_Db::Save($model) — а лучше Model_Name_Service::Save($model);
а что мешает реализовать $model->save() как:
function save()
{
Model_Name_Service::Save($this);
}
а в чем смысл?
Модель должна будет знать о существовании Model_Name_Service::Save.
В идеале модель «вещь в себе», она ничего не должна знать о том, как и где она хранится, как отображается, откуда приходят управляющие сигналы (вызовы методов), у неё просто есть состояние, которое она может показать кому-то и изменить, если кто-то попросит. В модели должна содержаться только данные и логика предметной области. Сущности модели должны зависеть только от других сущностей модели, но не от внешних сервисов.
В идеале модель «вещь в себе», она ничего не должна знать о том, как и где она хранится, как отображается, откуда приходят управляющие сигналы (вызовы методов), у неё просто есть состояние, которое она может показать кому-то и изменить, если кто-то попросит. В модели должна содержаться только данные и логика предметной области. Сущности модели должны зависеть только от других сущностей модели, но не от внешних сервисов.
Вы пытаетесь в одном посте рассказать человеку о целой методологии, которую он не воспринимает «на слух», находясь в смысловой зависимости отдельно взятого шаблона управления данными. Лучше бы дали ему ссылку на какую-нибудь книжку или статью в вики :)
www.infoq.com/news/2006/12/domain-driven-design
en.wikipedia.org/wiki/Domain-driven_design
www.infoq.com/news/2006/12/domain-driven-design
en.wikipedia.org/wiki/Domain-driven_design
небольшой ОФФ:
Написал вам на почту info@livestreetcms.com по поводу добавления сайта в ваш каталог и тишина, как быстро вы рассматриваете заявки на добавление?
Написал вам на почту info@livestreetcms.com по поводу добавления сайта в ваш каталог и тишина, как быстро вы рассматриваете заявки на добавление?
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Новые функции в репозитории фреймворка: ORM/ActiveRecord