Тема диплома: создание ORM на PHP с применением последних нововведений?

Question

[Антон Медведев]

Нужно писать диплом. Придумал тему: создание ORM на PHP с применением последних нововведений (примеси, позднее статическое связывание, генераторы, финализаторы).

Как вы думаете подойдет ли такая тема?

Comments

[Антон Медведев]

Посоветуйте так же каких-нибудь книжек по ORM на которые можно сослаться.

[Сергей Протько]

Может по паттернам програмирования и по работе с базами данных?

Answer 1

[Sergey Lerg]

Грамотная ORM совсем не проста в реализации. Да и их количество не такое уж и маленькое.
Интересует именно PHP?

Comments

[Антон Медведев]

Да, именно на PHP. ORM действительно много. Сам пользуюсь доктриной, очень нравится. Но диплом делать нужно =)
Поэтому вот думаю что лучше сделать в своей ORM. Основной правило при разработке будет: правило наименьшего удивления.

Answer 2

[Никита Гусаков]

Напишите. Доктрина несет в себе кучу багов, неточностей. Например фактически невозможно пользоваться типом date как первичным ключом, без переопределения типа на свой с __toString. А еще у нее не удобный query-builder, я думаю с трейтами можно сделать в сто раз лучше) Только не делайте AR, это явно не так интересно)

Comments

[Сергей Протько]

и чем вам помогут трейты?

[Никита Гусаков]

Создали WhereQueryPart и добавили к select, update, delete, а в insert не нужно. Я сходу уже не помню, но есть в qb некоторые вещи которые удобно делать трейтами

[Антон Медведев]

А я вот как раз думал об AR как о самой простой реализации. (наследоваться ниоткуда не нужно, все на трейтах)

[Сергей Протько]

мое личное мнение — ar это плохо. да, это легко реализуемо, но есть свои минусы: какого черта мои модели могут знать что-либо о том, как они хранятся в базе? Использование ar автоматически завязывает всю логику работы приложения на ваши модели, а именно на интерфейс предоставляемый трейтами/базовым классом. Согласитесь, это не слишком интересно. Намного интереснее паттер data mapper, с использованием прокси объектов для ленивой подгрузки связанных данных. Когда у вас есть ваши маленькое модельки и менеджеры записей/репозитории. В этом случае моделям без разницы где и как они хранятся, а логика приложения не завязана на конкретную реализацию слоя для работы с базой данных, а только на интерфейс ваших репозиториев.

hell0w0rd, можете привести абстрактный пример того, где трейты по вашему будут полезны (в контексте queryBuilder)?

[Сергей Протько]

Ну и так же как минус трейтов — они плохо покрываются тестами. Не зря же в silex отказались от трейтов и заменили их на serviceprovider (хотя вроде как поддержка трейтов была оставлена)

[Никита Гусаков]

Fesor, трейты являются особенностями определенных объектов. Позволяют добавить какую-то особенность к готовому классу. SQL запросы очень мощная вещь, но в разных типах запросов есть определенные уникальные конструкции. Вот чтобы эти конструкции не были доступны для всех типов запросов, а только некоторых — я считаю правильным использовать трейты

[Сергей Протько]

Возможно я вас не правильно понимаю, но трейты никак вам не помогут решить эту проблему. Наоборот, они только добавят проблем. Если вы говорите о том, что вам не нравится дублирование кода при работе с query buiilder, то тогда я с вами не соглашусь. Это дублирование — нормальное явление. Намного хуже когда люди пытаются писать какой-то один базовый метод и его дополнять (скажем метод возвращает querybuilder и потом на него докидываются еще штуки). Пусть уж код дублируется, зато его будет удобно изменять. Вещи, которые реально бесит постоянно копировать, допустим штуки вида removed=true для выборок проще запихнуть в фильтры доктрины.

Единственный реально живой кейс для трейтов — добавление какого-то функционала дополнительного. Например, добавление какого-либо дополнительного функционала. Скажем логирование. Причем с этим спокойно можно справиться применив декораторы. Если честно я пока не могу предложить реального примера, где трейты реально нужны. По сути это просто копи-пэйст кода на уровне среды исполнения. Ну и еще маленький минус, нормально покрывать тестами функционал реализованный с использованием декораторов довольно легко, чего нельзя сказать о трейтах.

Answer 3

[Сергей Протько]

а с каких это пор php поддерживает примеси? трейты != примеси, и использовать их для реализации orm как-то глупо.

Как тема диплома, ну… на фоне тех что я видел еще нормально, хотя как-то скучно.

Answer 4

[jonie]

И в чем заключается научная ценность диплома по такой теме? У нас вот например такие «дипломы» быстренько «заворачивали»…

Comments

[Антон Медведев]

Это инженерный диплом. Не все дипломы научные.

[Алексей Прохоров]

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

Answer 5

[lionsimba]

с применением последних нововведений...

… во что? каких нововведений?

Я бы конкретизировал.

И вместо «Создание» может быть «Разработка»?

«Разработка ORM на PHP с использованием One, Two, Three.»

Answer 6

[Алексей Прохоров]

Я бы обозвал «Разработка инструмента объектно-реляционного отображения на языке PHP <здесь в двух словах о главном отличии от других>». С технической точки зрения хрень, но в научной среде обычно название приводится к подобному виду.

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

Если получится действительно хорошее решение, обязательно пишите топик) Плюс ко всему, в публикации можете включить.

Comments

[Алексей Прохоров]

«с применением последних нововведений» — если оставить так, то следует переформулировать, что как правило является достаточно муторной задачей

Answer 7

[Вячеслав Плиско]

Тесты для диплома берите прямо с сайта доктрины, там ссылки на описание технологий и паттеронов.
По новинкам — основная польза от анонимных функций. На примере AR как-то так — User::with('comments', function(Query $query) { $query->where('active', '=', 1); })->get();
Мы на этапе выполнения запроса внедряем какой-то код, раньше можно было пользоваться эвалом, create_function или строить свой парсер конфигов (Symfony до сих пор ест этот кактус, лишь бы не юзать замыкания).
Трейты в доктрине используются для расширения возможностей knplabs.com/blog/knp-doctrine-orm-behaviors/, но фактически это замена
class User extends TraitName {}
на
class User { use TraitName; }
Тем более они не рантайм как миксины и в той же первой доктрине без trais, пользовалисьTemplates были приятнее.

Да и в целом, новинки в осном — синтаксический сахар, концептуально они разработку не меняют. Лучше просто пишите об ORM и DDD, как советовал megahertz