Полностью объектно-ориентированная структура в PHP

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

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

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

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

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

Ответ 1

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

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

Представление ООП таблиц/строк базы данных также возможно. Я использую DAO или ActiveRecord на ежедневной основе, Другой подход к проблемам ORM - Row Data Gateway и Table Data Gateway. Здесь пример реализации 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. Посмотрите полную реализацию здесь. Кстати, используя один из Intercepting Filters, вы можете обернуть возвращаемое представление нижним колонтитулом HTML и заголовком, поэтому вам не нужно беспокоиться о возврате полной страницы с вашего контроллера.

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

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

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

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

Проблемы управления доступом можно решить с помощью шаблона Business Delegate. Я описал это в своем fooobar.com/questions/315543/....

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

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

Ответ 2

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

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

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

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

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

Ответ 3

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

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

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

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

Ответ 4

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

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

ПОЧЕМУ это? Каковы основные преимущества, которые вы надеетесь реализовать? Если ответ "скорость", вы можете сделать одно, если это "простота кодирования", вы можете сделать другое, если это "опыт обучения", вы можете сделать thid
Каковы основные проблемы, которые вы пытаетесь решить? И что самое главное? Безопасность? Легкое создание пользовательского интерфейса? Масштабируемость?

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

Ответ 5

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

Остановите то, что вы делаете.
Это уже сделано до смерти.
Нажмите Zend Framework или CakePHP или даже это Рамка переделов.

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

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

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

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

из StackOverflow Podcast # 3.

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

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

Ответ 6

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

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

Ответ 7

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

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

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

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

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

Ответ 8

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

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

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

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

Класс кэширования
Класс проверки формы
Класс FTP
Классы возможностей плагинов

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

Ответ 9

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

Ответ 10

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

Обычно мы работаем с Zend Framework, и это в основном удивительно, но попытка unit test/test drive ZF-кода не намного отстает от мазохизма.

Если бы вы могли предоставить фреймворк, который заменяет части MVC ZF тем, что позволяет нам писать тестовый код, в то же время позволяя нам использовать библиотечные части ZF, я, в буквальном смысле, куплю вам пиво.

Я куплю вам два пива, если вы окажетесь в AJAX. Там существует огромная пропасть между фреймворком OO PHP и инфраструктурой JavaScript.

Ответ 11

Пожалуйста, не связывайтесь с существующей инфраструктурой

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

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

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

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

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

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

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

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

ООП/классы много лучших практик, которые приходят с ним - например, Инъекция зависимостей, SRP
Шаблоны проектирования, которые помогут вам написать код и структурировать вашу систему таким образом, что это делает многое логичным и легким. Для пример см. Wiki - SOLID
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) Я хотел нажмите, потому что это было интересно, и личная цель учиться и сортировать следующий этап, чтобы решить вопрос, который я застрял, и т.д.

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

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

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

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

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

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

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

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

При всем сказанном вы должны написать свою собственную фреймворк IF:

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

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

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

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

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

Ответ 12

Вы хотите создать точно то же самое, над чем я работал в течение нескольких лет, и результатом является Agile Toolkit.

Очень простая генерация страниц CRUD

$page->add('CRUD')->setModel('User');

разбиение на страницы на основе AJAX

Вся разбивка на страницы и многое другое реализованы через встроенную поддержку AJAX и Object Reloading. Ниже код показывает тематическую кнопку со случайной меткой. Кнопка перезагружается, если щелкнуть, показывая новый номер.

$b=$page->add('Button')->setLabel(rand(1,50));
$b->js('click')->reload();

Валидация формы на основе Ajax, если возможно, или очень простая форма проверки

Все проверки формы основаны на AJAX. Ответ от сервера - это цепочка JavaScript, которая указывает браузеру либо выделять и отображать сообщение об ошибке, либо перенаправлять на следующую страницу, либо выполнять любое другое действие javascript.

Сортируемые таблицы

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

Возможность редактирования HTML-шаблонов с использованием PHP

Это кажется неуместным и неправильным. Шаблоны лучше в VCS.