Самая гибкая архитектура фреймворка для веб-разработки?

Question

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

Цели, которые я поставил перед этой структурой: гибкость в способах достижения результата; максимальный комфорт для разработчиков; соединительные модули, такие как LEGO & reg; блоки; много типов ввода, много типов вывода, один формат для обработки.

Целями, которые не являются приоритетными, являются скорость, использование предприятия и зарабатывание денег. Это должен быть проект с открытым исходным кодом.

Краеугольным камнем этого дизайна является то, что весь контент до преобразования обрабатывается в XML (идея основана на системе EAI, с которой я работал, eGate). Уровень абстрагирования данных - надеюсь, умный ORM - сейчас не важен. Вывод будет сгенерирован с использованием XSLT или любых других пользовательских модулей для практически любого клиента - HTML для старых браузеров, XHTML / HTML5 для современных браузеров, простой HTML для мобильных клиентов, XML для AJAX / XMLRPC и т. Д.

Основные причины использования XML:

• это общеизвестный стандарт
• существующие инструменты, такие как XPath, SimpleXML и DOM для навигации и изменения содержимого
• XSLT, обеспечивающий мощный и унифицированный способ преобразования кода в любой теговый суп
• Я считаю, что разметка XML очень легко читаема, поэтому я не думаю, что преимущества JSON или YAML имеют здесь значение
• Контент может быть легко сложен, и его порядок на самом деле не имеет значения, если он правильно преобразован с помощью XSLT

Процесс генерации страницы будет состоять из следующих этапов:

1. Предварительная обработка: инициализация модулей, обработка данных GPCS, применение шаблонов по умолчанию [XML]
2. Обработка / генерация: основная часть бизнес-логики, генерация раздутого XML с максимальным объемом данных (хотя, мы надеемся, оптимизирована, чтобы не генерировать баласт)
3. Обработка: некоторая дополнительная бизнес-логика, например, сокращение части разметки, подготовка к трансформации, отчетность, статистика и т. д.
4. Постобработка: синтаксический анализ XML с помощью механизма преобразования (наиболее вероятно, просто XSLT), вывод.

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

Итак, мой вопрос: за исключением скорости, в чем заключается недостаток этого решения? Где это может пойти не так как при разработке / обслуживании фреймворка, так и его приложений? Каковы недостатки этой архитектуры?

Answer 1

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

Answer 2

Я не уверен, какую «гибкую структуру» вам предложить. Все зависит от того, с чем вам удобно и от вашего личного вкуса.

Одна вещь, которую я знаю, это то, как это может показаться на первый взгляд привлекательным, это держаться подальше от XSLT. Делать вещи типа Hello World и простые примеры с XSLT довольно просто. Тем не менее, более сложные проекты становятся полностью неуправляемыми (не говоря уже о нечитаемых) с XSLT. Мой опыт показывает, что это создает огромную нагрузку на проект.

Answer 3

То, что вы описываете, может быть реализовано с использованием tox . Он использует гибридную архитектуру MVC-ARS . Препятствием, которое я вижу, является стоимость, которую представляет tox из-за ее зависимости от Oracle. Конечно, поскольку он с открытым исходным кодом, вы можете преобразовать его в Postgresql .

Answer 4

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

Я задаю вопрос и, возможно, возьму вопрос о выборе PHP на внешнем интерфейсе. Я также думаю, что вы в значительной степени ошибаетесь в выборе XML.

Вот что я делаю:

1. Создание сервисного слоя с использованием Grails.org
2. Сохраняйте все ресурсы, которые могут быть RESTFUL в состоянии покоя
3. Используйте плагин X-fire в Grails для создания любых SOAP-сервисов, которые нужно построить
4. Воспользуйтесь преимуществами GORM и RAD в Grails, чтобы сократить время разработки.
5. Создание клиентов на языке или платформе X или Y для использования этих услуг.

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

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

Answer 5

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