Полностью объектно-ориентированный фреймворк в PHP - PullRequest
Новая
       16

Полностью объектно-ориентированный фреймворк в PHP

17 голосов
/ 11 февраля 2009

Я хочу создать 100% объектно-ориентированный фреймворк на PHP без процедурного программирования вообще, где все является объектом. Очень похоже на Java, за исключением того, что это будет сделано в PHP.

Есть ли какие-либо указатели на то, какими функциями должна обладать эта вещь, должна ли она использовать какие-либо из существующих шаблонов проектирования, например MVC? Как можно было бы создавать объекты для каждой таблицы в базе данных и как отображать шаблоны HTML и т. Д.?

Пожалуйста, не связывайтесь с существующей платформой, потому что я хочу сделать это самостоятельно, в основном в качестве учебного упражнения. Вы будете лишены права голоса за ссылку на существующую платформу в качестве вашего ответа и высказывание «это делает то, что вы хотите».

Некоторые функции, которые я хотел бы иметь:

  • Очень простое создание страницы CRUD
  • Пагинация на основе AJAX
  • Проверка формы на основе Ajax, если это возможно, или очень простая проверка формы
  • Сортируемые таблицы
  • Возможность редактировать шаблоны HTML с использованием PHP

Ответы [ 12 ]

30 голосов
/ 25 февраля 2009

Я прошел через многие проблемы в вашем списке, поэтому позвольте мне уточнить, как я справляюсь с этим. Я также увлекаюсь ООП и нахожу объектные техники чрезвычайно гибкими и мощными, но элегантными (если все сделано правильно).

MVC - да, да ладно, MVC - это стандарт для веб-приложений. Это хорошо документированная и понятная модель. Кроме того, он делает на уровне приложений то, что ООП делает на уровне классов, то есть он разделяет вещи. Хорошим дополнением к MVC является шаблон Intercepting Filter . Это помогает прикрепить фильтры для предварительной и последующей обработки запросов и ответов. Обычно используется регистрация запросов, тестирование, проверка доступа, кэширование и т. Д.

OOP представление таблиц / строк базы данных также возможно. Я использую DAO или ActiveRecord ежедневно. Другой подход к решению проблем ORM - Шлюз данных строк и Шлюз данных таблиц . Вот пример реализации TDG с использованием интерфейса ArrayAccess.

HTML-шаблоны также могут быть представлены в виде объектов. Я использую объекты View вместе с шаблоном Smarty. Я считаю эту технику чрезвычайно гибкой, быстрой и простой в использовании. Объект, представляющий представление, должен реализовывать метод __set, чтобы каждое свойство передавалось в шаблон Smarty. Дополнительно должен быть реализован метод __toString для поддержки вложенности представлений. Смотрите пример: 

$s = new View();
$s->template = 'view/status-bar.tpl';
$s->username = "John Doe";
$page = new View();
$page->template = 'view/page.tpl';
$page->statusBar = $s;
echo $page;

Содержимое view/status-bar.tpl: 

<div id="status-bar"> Hello {$username} </div>

Содержимое view/page.tpl: 

<html>
<head>....</head>
<body>
    <ul id="main-menu">.....</ul>
    {$statusBar}
    ... rest of the page ...
</body>
</html>

Таким образом, вам нужно всего лишь echo $page, и внутреннее представление (строка состояния) будет автоматически преобразовано в HTML. Посмотрите на полную реализацию здесь . Кстати, используя один из фильтров перехвата, вы можете обернуть возвращаемое представление нижним колонтитулом и заголовком HTML, чтобы вам не пришлось беспокоиться о возврате полной страницы из вашего контроллера.

Вопрос о том, использовать ли Ajax или нет, не должен быть важным во время разработки. Фреймворк должен быть достаточно гибким для собственной поддержки Ajax.

Проверка формы - это определенно то, что можно сделать в ОО манере. Создайте сложный объект валидатора, используя Composite pattern . Составной валидатор должен перебирать поля формы и назначенные простые валидаторы и давать вам ответ Да / Нет. Он также должен возвращать сообщения об ошибках, чтобы вы могли обновить форму (через Ajax или перезагрузку страницы).

Другим удобным элементом является класс автоматического перевода для изменения данных в БД, чтобы они подходили для пользовательского интерфейса. Например, если у вас есть поле INT (1) в БД, представляющее логическое состояние, и вы используете флажок в HTML, который приводит к пустой строке или "on" в массиве _POST или _GET, вы не можете просто присвоить одно другому. Наличие службы перевода, которая изменяет данные так, чтобы они подходили для View или db, - это чистый способ очистки данных. Кроме того, сложность класса перевода не засоряет ваш контроллерный код даже во время очень сложных преобразований (например, тот, который преобразовывает синтаксис Wiki в HTML).

Также i18n проблемы могут быть решены с использованием объектно-ориентированных методов. Мне нравится использовать функцию __ (двойное подчеркивание) для получения локализованных сообщений. Функция вместо выполнения поиска и возврата сообщения дает мне объект Proxy и предварительно регистрирует сообщение для последующего поиска. Когда объект Proxy помещается в View, а представление преобразуется в HTML, бэкэнд i18n выполняет поиск всех предварительно зарегистрированных сообщений. Таким образом, выполняется только один запрос, который возвращает все запрошенные сообщения.

Проблемы управления доступом Проблемы могут быть решены с использованием шаблона Business Delegate. Я описал это в своем другом ответе Stackoverflow .

Наконец, если вы хотите поиграть с существующим кодом, полностью ориентированным на объект, взгляните на Tigermouse framework . На странице есть несколько диаграмм UML, которые могут помочь вам понять, как все работает. Пожалуйста, не стесняйтесь брать на себя дальнейшее развитие этого проекта, так как у меня больше нет времени работать над ним.

Приятного взлома!

17 голосов
/ 11 февраля 2009

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

Если учесть, сколько времени потребуется, чтобы построить хорошую платформу, потраченное время на изучение того, что вам нравится, и ненависть к существующим решениям, будет бледнее в сравнении. Вам даже не нужно просто смотреть на PHP-фреймворки. Rails, Django и т. Д. Все популярны по определенной причине.

Создание структуры - это полезно, но вам нужен четкий план и понимание поставленной задачи, в которой и начинается исследование.

Некоторые ответы на ваши вопросы:

  • Да, вероятно, он должен использовать MVC, поскольку парадигма контроллера представления модели хорошо переносится в мир веб-приложений.
  • Для создания моделей из записей в таблицах в вашей базе данных изучите ORM и шаблон Active Record. Существующие реализации для исследования, о которых я знаю, включают Doctrine, более подробную информацию можно найти, выполнив поиск здесь.
  • Для всего, что связано с AJAX, я предлагаю использовать jQuery в качестве отправной точки, так как он очень облегчает запуск и запуск AJAX.
6 голосов
/ 11 февраля 2009

Создание собственного фреймворка - хороший способ получить оценку некоторых вещей, которые могут происходить под капотом других фреймворков. Если вы такой же перфекционист, как я, это дает вам хороший повод агонизировать за каждую мелочь (например, должен ли этот объект называться X или Y, должен ли я использовать для этого статический метод или метод экземпляра).

Я написал свой собственный (почти полностью OO Framework некоторое время назад), так что вот мой совет:

  • Если вы раньше работали с другими фреймворками, подумайте, что вам понравилось / не понравилось, и убедитесь, что у вас есть именно то, что вы хотите.
  • Мне лично нравится шаблон MVC, я бы не мечтал сделать проект без него. Если вам нравится MVC, сделайте это, если не хотите.
  • Если вы хотите заняться JavaScript / AJAX, используйте библиотеку JavaScript. Кодирование всего вашего собственного JavaScript с нуля учит вас немного о DOM и JavaScript в целом, но в конечном итоге это пустая трата времени, вместо этого сосредоточьтесь на улучшении вашего приложения / фреймворка.
  • Если вы не хотите внедрять другую платформу оптом, посмотрите, есть ли другие компоненты с открытым исходным кодом, которые вам нравятся и которые вы хотели бы использовать, такие как Propel , Smarty , ADOdb или PEAR компоненты . Написание собственного фреймворка не обязательно означает написание всего с нуля.
  • Используйте шаблоны проектирования там, где они имеют смысл (например, синглтоны для доступа к базе данных), но не зацикливайтесь на них. В конечном счете, делайте все, что вы думаете, чтобы получить самый лучший код.
  • Наконец, я многому научился, углубившись в философию Ruby on Rails , вы можете никогда не использовать RoR (я этого не делал), но некоторые концепции (особенно Соглашение о конфигурации) действительно резонировал со мной и действительно повлиял на мое мышление.

В конечном счете, если ваши потребности не будут особенными, большинство людей будут более продуктивными, если они примут существующую структуру. Но повторное изобретение колеса научит вас больше о колесах.

5 голосов
/ 11 февраля 2009

С риском звучания glib, мне кажется, что это похоже на любой другой программный проект, в этом смысле:

Вам необходимо четко определить ваши требования, включая мотивацию и приоритеты:

  • ПОЧЕМУ это сделать? Какие ключевые преимущества вы надеетесь реализовать? Если ответ «скорость», вы можете сделать одну вещь, если это «простота кодирования», вы можете сделать другое, если это «опыт обучения», вы можете выполнить thid

  • Какие основные проблемы вы пытаетесь решить? И какие из них наиболее важны? Безопасность? Простое создание пользовательского интерфейса? Масштабируемость

Ответ на вопрос «какие функции он должен иметь» действительно зависит от ответов на вопросы, подобные приведенным выше.

4 голосов
/ 27 февраля 2009

Вот мои предложения:

  1. Прекратите то, что вы делаете.
  2. Это уже сделано до смерти.
  3. Нажмите эту Zend Framework или эту CakePHP или, может быть, даже эту Recess Framework .

Теперь мои причины:

... если вы вообще работали с разработчиками, вы работали с разработчиками, которые любят заново изобретать колесо без веской причины. Это очень, очень распространенная схема сбоев.

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

... «О, я собираюсь создать свой собственный фреймворк, создать свое собственное все», и все это будет круче, чем вещи, которые вы могли бы просто пойти и получить ...

из StackOverflow Podcast # 3 .

Итак, сэкономьте немного времени и поработайте над тем, что решает проблему для людей, например, веб-приложение, которое позволяет людям автоматически обновлять Twitter, когда ящик для мусора их кошки требует очистки. Задача «Объектно-ориентированный PHP Framework» решена. Какой бы фреймворк вы ни собрали вместе, он никогда не будет таким надежным, полезным или многофункциональным, как любая из свободно доступных, полностью поддерживаемых фреймворков СЕГОДНЯ .

Это не значит, что у вас не может быть опыта обучения, но зачем делать это в темноте, создавая структуру, которая превратится в бесполезный кусочек кода, оставляя вас без чего-либо, что можно было бы показать на время? Разработайте веб-приложение, чтобы люди могли им пользоваться и наслаждаться, я думаю, вы найдете этот опыт невероятно полезным и ОБРАЗОВАТЕЛЬНЫМ .

2 голосов
/ 27 февраля 2009

Это правда, что некоторые разработчики изобретают велосипед без уважительной причины. Но поскольку вокруг уже есть хорошие фреймворки, это не значит, что делать их самостоятельно - пустая трата времени. Я начал некоторое время назад без намерения использовать его для чего-то большего, чем просто упражнение. Я настоятельно рекомендую это сделать.

2 голосов
/ 23 февраля 2009

Я изначально начал создавать свой собственный фреймворк с идеалами, подобными вашим. Однако через пару месяцев я понял, что воссоздаю работу, которая была проделана много раз. В конце концов я нашел фреймворк с открытым исходным кодом, который легко расширяется, и использовал его в качестве основы для собственной разработки.

Функции, которые я реализовал самостоятельно:

  • Архитектура MVC
  • Объект аутентификации
  • Класс доступа к базе данных
  • Конфигурация перезаписи URL
  • Класс нумерации страниц
  • Электронная почта
  • Шифрование

Особенности, на которые я смотрел и думал, забудьте об этом! Я построю поверх кого-то еще:

  • Класс кеширования
  • Класс проверки формы
  • FTP класс
  • Классы плагин-способностей

Конечно, написание фреймворка, который превосходит опции с открытым исходным кодом, возможно, но зачем вам это беспокоить?

2 голосов
/ 11 февраля 2009

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

Тем не менее, я написал слой доступа к данным до того, как он почти полностью абстрагировал любой SQL. Код приложения может запрашивать соответствующий объект, и уровень абстракции делал много волшебства для извлечения данных только тогда, когда это было необходимо, без необходимости повторного извлечения, сохранения только после его изменения и поддержки помещения некоторых объектов в разные базы данных. Он также поддерживал реплицированные базы данных, уважал задержку репликации и имел интеллектуальный объект сбора. Он также был очень расширяемым: ядро ​​управлялось параметрами, и я мог добавить целый новый объект с примерно 15 строками кода - и получил всю магию бесплатно.

Я также написал механизм верстки CRUD, который использовался для значительного процента сайта. Ядро управлялось параметрами, поэтому оно могло запускать списки и редактировать страницы для чего угодно, как только вы написали список параметров. Он автоматически выполнял разбиение на страницы, поддерживал сохранение-новое-удаление и т. Д., Используя объектный слой выше. Он не был объектно-ориентированным сам по себе, но это могло быть сделано так.

Другими словами, объектно-ориентированная среда в PHP не только возможна, но и может быть очень эффективной. Все это было в PHP 4, кстати, и я несколько раз сталкивался с тем, что было возможно с объектами PHP 4. : -)

Я никогда не заходил так далеко, как центральный диспетчер, который называл объекты, но я не был далеко. Я работал с несколькими фреймворками, которые делают это, однако, и макет файла может быстро стать волосатым. По этой причине я бы выбрал систему диспетчеризации, которая настолько сложна, насколько это необходимо, и не более. Простое действие / представление (в любом случае это почти MVC) должно сделать вас более чем достаточно.

2 голосов
/ 11 февраля 2009

У меня есть идеальная ссылка для вас, мой друг: http://nettuts.com/tutorials/php/creating-a-php5-framework-part-1/. Это потрясающий учебник, на который я смотрел, и он не слишком потрясающий. Плюс осмотрите раздел PHP того сайта, на котором я увидел статью о CRUD. Что касается AJAX, посмотрите в другом месте, но вы должны начать с чего-то, и этот урок потрясающий.

Примечание: этот урок состоит из 3 частей, и я думаю, что он поднимает MVC во второй части, но начинает первую часть, используя другие методы.

1 голос
/ 27 февраля 2015

Пожалуйста, не ссылайтесь на существующую платформу

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

Я ни в коем случае не говорю, что мог бы писать лучше, чем "большие мальчики", но я (наряду с большинством из вас, я думаю) мог указать, почему некоторые вещи они делают плохо, даже если только потому, что они не конечный пользователь / не для разработчиков ...

Интересно, как поживает ваша структура, где-то 6 лет?
Вы все еще работаете над этим? Ты остановился?

Если вы напишите свой собственный фреймворк

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

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

В прошлом году я хотел изучать ООП / классы и более продвинутый PHP.
И написание моей собственной структуры было лучшим, что я сделал (на самом деле все еще делаю), поскольку я узнал намного больше, чем я ожидал.

На протяжении всего пути, который я выучил (назвать несколько):

  • ООП / Классы многие лучшие практики, которые идут с ним - такие как Инъекция зависимостей, SRP
  • Шаблоны проектирования, которые помогут вам написать код и структурировать вашу систему таким образом, что это делает многие вещи логичными и легкими. Для пример см. Wiki - SOLID
  • * 1038 Namespaces *
  • Обработка ошибок PHP и все функции, которые обеспечивает
  • Более надежное (и лучшее) понимание MVC и как его применять соответственно (поскольку нет четкого способа его использования, просто направляющие и лучшие практики).
  • Автозагрузка (классов для ООП)
  • Лучше стиль написания кода и более структурированный макет, и лучше навыки комментирования
  • Соглашения об именах (это интересно делать самостоятельно, даже если на основе общие практики).

И многие другие базовые вещи PHP, с которыми вы неизменно сталкиваетесь при чтении чего-либо.

Все это не только значительно улучшило мое понимание PHP и того, что с ним связано, до более продвинутого уровня, но и некоторые коммерчески / широко используемые методы и принципы.
И все это укрепило мою уверенность в использовании PHP в целом, что, в свою очередь, облегчает изучение.

Зачем писать каркас для изучения всего этого

Когда вы начинаете, вы изучаете основы - A (переменные), затем B (как написать базовую функцию) и т. Д.
Но это не займет много времени, когда вы пытаетесь изучить более продвинутые вещи, что для изучения и использования D и E, вы также должны изучить и понять F, G, H и J, и знать тех, кто вам нужен знать K, L и M, и чтобы узнать части L и M, вам сначала нужно понять N и O ...

Это становится минным полем, так как попытка научиться чему-то приводит к необходимости сначала изучить несколько других вещей, а эти другие вещи часто вызывают потребность в понимании различных других вещей.
И вы окажетесь в миле от того места, где вы начали, ваш разум покалывает и стреляет из него искрами, и открывается около 20 вкладок с различными продвинутыми PHP-вещами, ни одна из которых вас не устраивает на 100%.

Но со временем, с практикой и, безусловно, самоотверженностью, все это встанет на свои места, и вы оглянетесь назад на код, даже набор файлов / классов, и подумаете: «Я написал это…»?

Написание фреймворка очень помогло с этим "минным полем", потому что:

  • У меня были конкретные задачи, которые привели к необходимости учиться и реализовать другие вещи, но конкретные вещи. Это позволило мне сосредоточиться на меньшее количество вещей одновременно, и даже когда что-то различные другие вещи, вы можете вернуть его туда, где вы начали потому что вы работаете над чем-то конкретным. Вы можете сделать это с любое обучение, но если у вас нет какой-либо цели или конкретной задачи, вы сосредоточиться на, вы можете легко отвлечься и потеряться в эфире вещей для изучения.
  • У меня было что-то практичное для работы. Часто читая учебники о класс животных, и как классы кошек и собак расширяют животных и т. д., может быть запутанным Когда у вас есть реальная жизненная задача в вашем своем фреймворк, например, как мне управлять XYZ, то вы можете узнать, как классы работают легче, потому что у вас есть метод проб и ошибок и солидный требование, которое вы понимаете, потому что вы создали требование! Не только теоретическое чтение, которое ничего не значит обычно.
  • Я мог бы положить это, когда мой ум был взорван, хотя, как это было мое рамки (мой монстр Франкенштейна в начале: P) я хотел нажмите на, потому что это было интересно, и личная цель учиться и сортировать следующий этап, чтобы решить проблему, с которой я застрял и т. д.

Ты можешь делать это как хочешь. Возможно, это не лучшая практика, но пока вы пытаетесь выучить лучшие практики, со временем вы будете совершенствоваться и, вероятно, будете легче, чем просто читаете учебники, потому что вы контролируете, что и как вы делаете что-то. * * 1092

Подождите, я не должен заново изобретать колесо, хотя

Ну, во-первых, вы не можете заново изобрести колесо, это невозможно, так как вы просто сделаете колесо.

Когда люди говорят: «Не изобретай велосипед», они, конечно, подразумевают «уже есть фреймворки», и, если честно, они написаны опытными разработчиками.
Это не значит, что у фреймворков нет проблем или проблем, но в целом они довольно надежные, безопасные и хорошо написанные.

Но утверждение бессмысленно в отношении написания вашей собственной структуры!

Написание собственных рамок для учебных целей действительно полезно. Даже если вы планируете использовать его в коммерческих целях или для собственного веб-сайта, вы не просто «заново изобрели колесо», вы сделали что-то еще.
Ваш фреймворк не будет похож на другие, у него не будет много функций и возможностей, которые могут быть для вас главным преимуществом!

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

Но проект для обучения, который вы не используете в Интернете, идеален - или используйте его, в конце концов, когда вы достаточно продвинуты, чтобы знали , что это безопасно!

Учитывая все вышесказанное, вы должны написать свой собственный фреймворк IF:

  • Тебе это не нужно в ближайшее время! Это занимает много времени, как Есть так много аспектов, которые нужно учитывать, учиться и проб и ошибок приводит к рефакторингу (сначала много!)
  • Вы готовы читать, кодировать, тестировать, изменять, читать, кодировать и читать еще немного. В интернете много полезных советов для продвинутых PHP, большая часть которого сначала сногсшибательна, как чтение всего дизайна узоры. Но они в конечном итоге имеют смысл, и в конечном итоге помогают вам решать проблемы, с которыми вы сталкиваетесь, и как делать основа.
  • Желание тратить время и пытаться улучшить, и голова к наилучшей практике, особенно с безопасностью. Проблемы со скоростью не должны быть проблемой с небольшой платформой, и, кроме того, если у вас достаточно приличная система, вы можете обычно проводить рефакторинг и делать улучшения скорости. обычно, если у вас есть серьезные проблемы со скоростью, это означает, что вы выбрали интенсивные операции, которые обычно можно решить, выполнив это другим способом.

.

Без предыдущего опыта или глубоких знаний PHP вы, вероятно, потратите некоторое время на написание фреймворка, дальнейшее чтение и знание покажут вам, что ваш подход искажен, и поэтому вы можете удалить все и начать заново.
Не унывай от этого.
Я сделал именно это, так как я узнал очень много продвинутых шаблонов и способов ведения дел в течение первого месяца, я оказался там, где рефакторинг был бесполезен, и единственным вариантом был чистый холст с совершенно новым подходом.

Тем не менее, это было довольно приятно, так как я увидел гораздо лучшую структуру, принявшую форму, и я увидел, что начало не только улучшать основы фреймворка, но и понял, что это потому, что я лучше понимал продвинутый PHP.

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

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

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

Нет похожих вопросов

...