Сейчас веб-разработка сталкивается с большой проблемой - сверхнизкое повторное использование кода.

Как происходит, когда разработчик начинает делать свой проект, скажем, на PHP. Сначала он идет, например, на PHP Classes. Там очень много классов. Все разные. Каждый написано по-своему. У некоторых внешний интерфейс через один класс, у других через пять, у третьих через десять и два конфига. В результате требуется изучать архитектуру каждого класса, и, что самое важное, сайт из таких “компонентов” быстро не построишь.

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

И они сложные. Поэтому мало кто (в мировом масштабе) их осваивает. Поэтому мало готовых компонентов для этих фреймворков, и все равно многое надо писать самому. Компоненты от разных фреймворков не совместимы.

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

Есть, конечно, более “компонентные” решения, вроде Joomla и Drupal, но они не являются открытыми стандартами, они являются продуктами со своей историей и они тяжеловесны.

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

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

Итак, Open Web Platform (OWP). OWP является компонентной системой. А именно: каждый блок проекта является “компонентом”, который общается с другими компонентами не напрямую, а через общий интерфейс “ядра платформы”. Пример:


В этом примере некий управляющий компонент shell обращается к компоненту auth, который производит авторизацию пользователя, после чего возвращает user_id. Компонент shell ничего не знает о компоненте auth. Не знает, на каком тот написан языке. Из каких состоит классов. Как он разработан. Где он находится в файловой системе. Он даже может оказаться на другом сервере. Компоненту shell и его разработчикам это безразлично - они знают имя компонета auth и вызовы, которые можно ему направлять, этого совершенно достаточно.

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



Все единообразно. Если посмотреть на Class Diagram любого сколь-либо сложного “обычного” проекта, мы всегда увидим клубок ниток. Здесь мы имеем единую шину, к которой динамически подключаются разные устройства-компоненты.

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



Что находится “за” этим интерфейсом - не важно. Вам достаточно написать мануал (не сложнее команды man в Linux) для вашего компонента, после чего вы можете делать с бекэндом все, что захотите.

При этом компонент даже не обязательно должен быть написан как на PHP, как здесь. Ядро может иметь “драйвера” для различных языков разработки и вызывать компоненты между языками.

Оцените, как при таких условиях упрощается рефакторинг. При рефакторинге “внутри” компонента другие не затрагиваются никак, поэтому проблем не возникает. Если же рефакторинг касается внешнего интерфейса, то этот интерфейс простой, поэтому его изменение сводится к простому “поиск и замена” по всему проекту.

И это еще не все преимущества такого подхода. У нас есть компоненты, они все однотипны. Одни компоненты могут использовать другие. Значит, можно создать единый репозиторий с зависимостями, как для Linux. Тогда установка одного компонента автоматически повлечет за собой установку связанных. Поскольку все они независимы друг от друга, вы вообще не заметите то, что что-то там установилось. Все просто работает.

Разные компоненты могут нести разный функционал. Одни могут быть “базовыми”, вроде mysql-компонента, другие реализовывать логику проекта, третьи генерировать HTML-блоки для вторых (VC и M из MVC соответственно). Однако архитектурно они все являются однотипными.

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

А теперь сравните это с описанием “современной” разработки из первых абзацев.

Итак, сейчас я занимаюсь разработкой такой платформы. Она частично написана. Однако, для того чтобы такая платформа стала мировым стандартом, мне нужны мнения разработчиков. Только они знают, как надо скорректировать код и архитектуру такой платформы, чтобы им было удобно ей пользоваться. Я с радостью выслушаю все требования, которые вы выскажите. Я особенно буду рад, если встреча произойдет вживую, с перекрестным изучением кода (у меня есть возможность организовать это в офисе на берегу Москвы-реки, с хорошей экологией и бесплатным Wi-Fi).

Жду ваших писем.

Дмитрий Лейкин

Email: [email protected]
Skype: dilesoft
ICQ: 67937292
Телефон: +7 (903) 125 33 68

Идея понятна, но как по мне это глупость. Посмотри на фримворк Yii. Там тоже всё разделено. Щас каждый будет(каждая компания и разработчик) по разному реализовывать эти компоненты, и твоя архитектура ничем не будет отличатся от других. 

Так в том то и дело, что компоненты ВНУТРИ реализованы по-разному, но если будет соблюдаться внешний интерфейс, то они все останутся совместимыми!

 Это из какой-то книжки 2004 года?

 Неверно.
Многие фреймворки расчитаны на loose coupling.

 Мало кто (в мировом масштабе) имеет опыт работы 3+ лет. И, мне кажется, эти 2 цифры сравнимы 


А какие отличия от:

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

 Как бы это и в интаксисе есть: имя_компонента::вызов().
Данная штука называется инкапсуляцией.
ru.wikipedia.org/wiki/Инкапсуляция_(программирование)


 Предлагаю подумать, почему это минус.

 А в чем тогда разница с методом 2004 года? Для них абсолютно так же можно сделать адаптеры. Только без бессмысленных вызовов в ядро.
Материал: ru.wikipedia.org/wiki/Адаптер_(шаблон_проектирования)

 Сейчас не 2004 год. Предпосылки создания были не верны, в 2011 так не делают.

Добавлено через 1 минуту и 43 секунды
 Пичалька. Учи основы основ ООП. Могу конкретнее, если интересует, но в твоих интересах учить все.

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

Добавлено через 3 минуты и 20 секунд

И как же делают сейчас?

 Есть PEAR(хотя я считаю его тоже устаревшим) - набор библиотек в одном стиле.
Есть Zend Framework, который можно использовать не как фреймворк, а как набор библиотек.

 У нас много языков? Про принципы читай в посте выше: адаптеры.

 Ложь. IDE умеют определять на лету типы функций(несмотря на то, что язык динамический), количество параметров и т.д.
И все это подсказывать.

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

PEAR не универсален. Там мало компонентов, нельзя из кирпичиков сделать почти готовый сайт. У фреймворков тоже.



Так я про это и говорю. Кстати, можно сделать OWP таким, чтобы там и IDE работал, с помощь кодогенерации оберток. Уже пишу это.



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

DileSoft, окей, все это понятно, типа адаптер ты сделал, косяки с IDE появились(ошибки на момент редактирования стали ошибками момента исполнения).
Но плюсы какие? Хоть ОДИН плюс?

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

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

А теперь вопрос номер 1: зачем нужны адаптеры?

А зачем вы их используете?

Если я правильно Вас понял, вы как раз собираетесь заняться тем, о чём написано в предложении выше. Простите за сарказм, но Вам не удалось освоить готовый фреймворк?

Если честно, мне не совсем понятно, что Вы хотите реализовать? Аналог ASP.net (.net платформы) на PHP? Возможно, в таком случае, действительно стоить посмотреть в сторону именной этой технологии?

Это сообщение отредактировал(а) WolfAlone - 3.7.2011, 00:17

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

"С проблемой надо переспать"=)