Почему использование Oracle Application Express для веб-приложения?

Обратите внимание, что мой опыт связан с APEX 2.x-3.0.

Я использовал Apex для нескольких внутренних приложений в течение 12 месяцев, но в конце концов отказался от него для ASP.NET.

Некоторые евангелисты Oracle утверждают, что он способен создавать высокодинамичный контент наравне с более распространенными средами, такими как ASP.NET/J2EE. Технически это правда, но технически это также верно, что вы можете пересечь Атлантику в одном каноэ. Если у вас возникает соблазн погрузиться в APEX-проект даже средней сложности, я предлагаю вам взглянуть на APEX-образец простого дискуссионного форума . Сравните это с ASP. Пример дискуссионного форума .NET MVC или реализация RoR.

Сказав, что:

Хороший

• Невероятно легко создать респектабельное веб-приложение с вводом базовых данных CRUD, простой отчетностью и заполнением его данными. Если вы ИТ-специалист, которому было поручено объединить беспорядочные базы данных Excel / Access компании в центральную базу данных / веб-среду, вам следует взглянуть на APEX, он очень хорошо подходит для этой задачи. Если вы ожидаете, что объем вырастет до чего-то даже умеренного, я бы сразу перешел к более гибкой структуре.

• Если вы гуру DBA / PLSQL, но не имеете опыта традиционной веб-разработки, вы будете хорошо подготовлены к тому, чтобы раскрыть существующую бизнес-логику в веб-приложении, не прибегая к HTML / CSS / JavaScript, если вы этого не хотите.

• Форум поддержки APEX содержит массу информации и хорошо укомплектован разработчиками APEX.

Плохое

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

• Веб-интерфейс - это не круто. Отладка болезненна.

• Контроль версий? Кому нужен контроль версий?

• Когда вам (неизбежно) нужно сделать что-нибудь за пределами ограниченного объема фреймворка, вам придется поработать руками с PL / SQL. Написание бизнес-логики для базы данных - это нормально, но создание HTML из процедур PL / SQL в 2007 году казалось неприятно архаичным.

• Учитывая большое количество скрытых мест, где можно скрыть страницу и логику перенаправления, выполнение программы сложно одновременно визуализировать и естественно не способствует модульному, разделяемому и повторно используемому коду. Разработчики ООП не будут впечатлены. С APEX можно иметь хорошо структурированные поддерживаемые приложения, но это сложнее, чем должно быть. Это очень далеко от MVC.

• Недопустимое количество ошибок фреймворка в используемых мной версиях. Я надеюсь, что в последних версиях ситуация улучшилась, но парадигма интеграции IDE в саму платформу APEX вызвала у меня одни из самых мрачных, разрушающих душу сеансов отладки в моей жизни . В качестве примера я пытался воспроизвести периодически возникающую ошибку, из-за которой пользователь терял данные сеанса. Используя всплывающее окно с информацией о сеансе, я заметил, что иногда данные о сеансе меняются, когда этого не должно быть. Я потратил 2 дня, безуспешно пытаясь найти ошибку в своем коде. Почти в бреду, Я совершенно случайно заметил, что могу воспроизвести ошибочные данные сеанса в окне отладки , но само приложение не перейдет в состояние ошибки . Мое сердце упало, когда я понял, что могло случиться. Позже Oracle подтвердила, что я обнаружил ошибку в APEX, из-за которой в окне информации о сеансе периодически показывались данные из предыдущего сеанса. Я потратил 2 дня на отладку ошибки, связанной с сеансом, с ошибочным окном отладки сеанса. Это было последнее приложение Apex, которое я создал.

• PL / SQL не является и никогда не будет следующим большим событием в веб-разработке. Проработав некоторое время с APEX, я понял, что это не сделает меня лучшим веб-разработчиком. Освоение APEX действительно связано с PL / SQL. Это нормально, если вы планируете сосредоточить свою карьеру на технологиях Oracle, просто имейте в виду, что APEX настолько косвенен направлению основных веб-технологий, что переносимый набор навыков, который вы можете перенести из APEX на другие веб-платформы, минимален.

Если вы рассматриваете APEX для обеспечения простого ввода данных и создания отчетов через Интернет, на него стоит обратить внимание. Если вы ищете альтернативу .NET / JAVA / PHP для динамического веб-контента и богатого взаимодействия с пользовательским интерфейсом, я бы посоветовал вам поискать в другом месте.

Я вовлечен в огромный проект переместить 5 000 модулей приложение Форм Oracle в ВЕРШИНУ. Это - экстремальное использование ВЕРШИНЫ, но она работает просто великолепно. Это - полный миф, что ВЕРШИНА подходящая только для маленьких внутренних приложений, созданных DBAs, интернами или конечными пользователями: это, конечно, подходит для тех также (и более подходит, чем большинство других инструментов), но это может также использоваться для создавания чрезвычайно сложных приложений.

Для создавания сложного приложения (а не значение по умолчанию out-of-the поле APEX одно) Вам будет нужен кто-то в команде с навыками JavaScript и ком-то с навыками CSS. Но большинству разработчиков просто будет нужно МН / SQL первоначально.

это масштабируемый? Да: вероятно, более масштабируемый, чем большинство других решений! APEX добавляет очень мало служебное к серверу базы данных, и только самый минимальный из серверов приложений требуется. "Размер Facebook"? Я не знаю наверняка, но я не вижу, почему не, принимая у Вас есть база данных Oracle по машине, большой и достаточно мощной для обработки "данных" размера Facebook и объемов сделок. Как любой проект Oracle, масштабируемости препятствуют главным образом плохие проектирования баз данных и плохо пишет SQL, не инструмент. Не многие люди когда-либо создают "системы" размера Facebook хотя: Вы?

ВЕРШИНА является платформой, которая использует базу данных и МН / SQL для создания веб-страниц. Если можно выяснить то, что вывод к браузеру должен будет быть Вами, может создать его в ВЕРШИНЕ. Если Вы находите, что любая часть платформы, запрещающей Вас, может записать МН процедуры / процедуры SQL и представить их веб-серверу непосредственно, но все еще использовать в своих интересах безопасность, вход, состояние сеанса, и т.д. что система ВЕРШИНЫ справляется для Вас.

необходимо знать МН / SQL, SQL, HTML, JavaScript и CSS. Уверенный интерфейс похож на приложение записи больших данных, но данные, которые Вы вводите, главным образом будут фрагментами кода на каждом из этих языков.

Это масштабируется, а также база данных делает. Это обычно использует Apache в качестве веб-сервера, но только используется, чтобы служить статическим файлам и пасовать назад запросы к базе данных, где веб-страницы создаются МН / КОДОМ SQL в схеме ВЕРШИНЫ. Можно использовать Ajax для уменьшения размера трафика, перемещающегося вверх и вниз по каналу. Можно установить кэширование для определенных объектов, списков, регионов страницы, страниц, и т.д.

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

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

Удача.

Greg

Я не уверен, почему Вы не считаете МН / SQL язык программирования...

ВЕРШИНА идеальна для внутренних приложений, где Вы хотите легкий UI сверху своих данных. Можно создать это скорее легко, не имея необходимость писать любой код.

я также нахожу, что ВЕРШИНА очень хороша для разработки меньших клиентских приложений. Я не хотел бы создавать гигантское приложение, которое будет иметь сотни разработчиков, работающих над ним с помощью ВЕРШИНЫ. Но если у Вас будет случай, где 3 или 4 разработчика создают небольшой сайт, ВЕРШИНА, вероятно, будет так же хороша как Java/PHP/ASP.Net/whatever принятие одинаково квалифицированных разработчиков. Если Ваши разработчики, у всех есть большое экспертное знание ASP.NET, например, они собираются иметь кривую обучения для записи приложений ВЕРШИНЫ. У Вас был бы, по крайней мере, тот же уровень трудности, тем не менее, если бы у Вас был набор МН попытки разработчиков / попытки разработчиков SQL изучить, как создать сайты ASP.NET.

Сайт поддержки Метассылки Oracle был записан в Вершине, таким образом, это определенно масштаб CAN. Они мигрируют на более новый основанный на Flash сайт поддержки теперь все же. Я понимаю, что они получили ту платформу через aquisition другой компании, вместо того, чтобы создать его в ответ на любые пределы Вершины.

, Если бы Вы хотите 'супер сексуальный' с каким-либо веб-приложением, необходимо было бы, вероятно, пойти Flash/Silverlight/воздух. Под этим любой основанный на HTML сайт, включая Вершину один, может быть prettied с JavaScript. Библиотека JQuery будет включена в со следующей основной версией Вершины (4.0), хотя можно включать это (или любая другая библиотека) теперь.

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

, В то время как Вы заблокированы в базу данных Oracle, я не получаю блокировку 'платформы' "довод"против"" в статье. Oracle доступна в Windows, Linux и AIX (среди других). Это - намного меньше блокировки, чем ASP / SQL Server.

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

GUI обрабатывается шаблонным (HTML) страницы Apex, CSS и небольшим количеством JavaScript для улучшения пользовательского опыта. Вся бизнес-логика помещается в МН пакеты / пакеты SQL. Это является ключевым для подавания Вашей заявки, легкой поддержать и снова использовать бизнес-логику в других приложениях Вершины и от других клиентских инструментов, таких как C# WinForms, Delphi, приложения Java, и т.д.

Что касается производительности, механизм Вершины добавляет мало служебное и время отклика, и масштабируемость Вашего приложения зависит в основном от качества Ваших SQL-запросов (и модель данных). Думайте об этом этот путь: С Вершиной, единственной вещью между Вашим пользователем и базой данных тонкий слой МН / SQL. Это - только здравый смысл, что это должно быть быстрее, чем типичная.NET или JAVA-приложение, которое имеет семнадцать слоев сложности (обычно включая большое количество веб-сервисов и объектно-реляционных слоев отображения) между GUI и базой данных.

На моем проекте мы используем ВЕРШИНУ Oracle для внутренних представлений нашей системы. Это работает очень хорошо с этой целью.

нет никакого требуемого программирования. PL/SQL и даже SQL являются дополнительными. В результате наш DBA и оператор могут прессовать представление к их симпатии.

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

я не хотел бы основываться на стоящем с клиентом сайте ВЕРШИНА.

По вопросу о масштабируемости, одна хорошая вещь о ВЕРШИНЕ состоит в том, что она основывалась на Oracle. Внимание на запись хорошего SQL и разработку таблиц правильно и вещей должно масштабироваться очень хорошо. Я был бы более обеспокоен тем, чтобы заставлять достаточно пользователей для масштабируемости быть проблемой.

Если требуется видеть внешний веб-сайт, сделанный в ВЕРШИНЕ, я предлагаю смотреть Группа пользователей Инструментов Oracle , сайт, или Спрашивают Tom. Оба являются большими, часто используемые сайты с большой настройкой.

Ваше впечатление от статьи Wikipedia корректно. Единственное знание программирования, в котором Вы нуждаетесь, МН / SQL. Если большая часть Вашего сайта будет простыми отчетами, Вы не должны даже писать SQL-запросы, и интерфейс мастера создаст запрос и вывод для Вас. Если Вы захотите прохладную клиентскую работу, то необходимо будет знать CSS и JavaScript. МН / SQL только для более сложного подтверждения правильности данных.

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

Теперь ключевое слово здесь - data centric, так как я не согласен со многими другими DBA, что все приложения ориентированы на данные (вы знаете тип DBA, которые до сих пор думают, что ODBC означает ORACLE Database Connectivity). Конечно, все приложения включают в себя данные, но все ли приложения ориентированы на данные? Я сомневаюсь, так же, как я сомневаюсь, что APEX когда-либо будет использоваться для обработки изображений или мобильных игровых приложений. Однако, несмотря на всю шумиху с RIA и Web 2.0, факт остается фактом: большинство предприятий вокруг нас жаждут этих простых старых приложений, ориентированных на данные, и Oracle является лучшей базой данных, и я могу заверить Вас, что Oracle и APEX могут справиться с гораздо большим, чем масштабируемость Facebook, при условии, конечно, что Вы вложили ту же сумму денег, что и ребята из Facebook в базовую инфраструктуру.

Кстати, я также ненавижу дизайн темы APEX от Oracle (ужасный непрофессиональный пользовательский интерфейс, просто представьте его в качестве основного пользовательского интерфейса для банковского или авиационного бизнеса), ограниченные возможности (хотя это, кажется, вот-вот изменится в будущем), многие другие вопросы (профессиональная отчетность в формате PDF без оплаты лицензии Enterprise Database для издателя BI? ), но прежде всего это маркетинг APEX как замены Access или Excel, потому что он производит плохое впечатление на детей, и я могу заверить тебя, мой друг, что никогда бы не позволил детям прикасаться к моим базам данных :)

Видишь ли, у Oracle есть жемчужина под названием PL/SQL, которая была усовершенствована в течение многих лет, чтобы обрабатывать данные гораздо более интуитивным способом, чем любой другой язык. Теперь, когда жемчужина увядает с медленной смертью форм/отчетов, и я уверен, что ни один новый выпускник никогда не удосужится изучать ее строго для процедур, хранящихся в базе данных (просто посмотрите на бушующую войну между разработчиками Java и .Net и вы поймете, что как только вы прикоснетесь к фигурным скобкам {} все остальное становится ересью). Увы, для тысяч и тысяч отличных разработчиков PL/SQL APEX остается единственным убежищем, где они могут оставаться продуктивными и разрабатывать выдающиеся приложения, ориентированные на данные, и без APEX PL/SQL наверняка станет следующей КОБОЛЬЮ. Именно поэтому сообщество PL/SQL заставит компанию Oracle трансформировать APEX в платформу класса А гораздо более мощную, чем та, которую мы видим сегодня. Или так, или попрощайтесь с PL/SQL и соедините фронт фигурными скобками (кстати, никогда не бывает плохой идеей хотя бы попробовать разные технологии, когда вы разработчик, по крайней мере, вы понимаете, почему с другой стороны не так уж и необязательно зеленее).

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

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

Хороший

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

Плохой

• Отладчик ужасен. Если вы использовали Visual Studio (и даже старые версии Microsoft Access), то вы влюбитесь в отладчик. Никаких точек останова, отладочные сообщения выплескиваются на экран в большом списке, приходится вручную распечатывать отладочные сообщения на экран. Ужасно. Причина многих, многих часов, потерянных на поддержку.

• Как только ваше приложение становится сложным или требует какой-либо богатой функциональности, вы должны прибегнуть к Javascript и HTML / CSS хакам, которые делают отладку и поддержку еще более сложными (хотя вы можете использовать такие инструменты, как Firebug или Visual Studio, чтобы помочь в этом).

• Мы столкнулись с необъяснимыми ошибками состояния сеанса, и таблицы стилей становятся "отщепленными" от приложения без объяснения причин - и это лишь некоторые из проблем.

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

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

В целом

Я бы сказал, что во что бы то ни стало используйте Apex для простых CRUD-приложений. Для чего-нибудь более чем легкой сложности используйте .Net или Java. Я бы не обратил внимания на статью в Wiki об Apex, так как она очень перекошена. Обратите внимание на то, как "сложная отладка" (на мой взгляд, самая большая неудача) была стерта из статьи.

Кое-что, к чему нужно быть очень осторожным, так это нелепое утверждение, что вы можете быстро конвертировать базы данных Access прямо в Apex. Да, это сработает, если БД Access очень, очень простая. Что угодно умеренно сложное, забудьте об этом, как мы это обнаружили.

Мы определенно не будем использовать ее для веб-приложений, только для внутренних. Просто есть слишком много трудностей, делая то, что вы воспринимаете как само собой разумеющееся, скажем, в .Net. Я знаю, что есть такие сайты, как AskTom, но они не совсем сложные. Увидим ли мы на нем следующий Facebook? Думаю, что нет - хотя я уверен, что кто-нибудь, читая это, будет иметь трещину в нем.

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

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

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

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

• Создайте представление со всеми данными, которые нужно получить для каждого экрана.
• Создайте единый пакет-оболочку для всех операций CRUD. (Я полагаю, это создание, чтение, обновление и удаление)

Вкратце:

НЕ ПОМЕЩАЙТЕ ЛОГИКУ ВАШЕГО ПРИЛОЖЕНИЯ В APEX.

Это мой совет. . . .

Мне очень понравилось читать ветку сверху вниз, так как это было похоже на жаркие дебаты. Напомним, что начало обсуждения было следующим: «Я считаю, что мы переходим на Oracle Apex для будущего развития ...» Джек, будучи программистом .NET, был обеспокоен решением своего руководства и подумал о том, чтобы найти контрфакты для Oracle Apex. что в конечном итоге привело к тому, что мы публично отмыли грязное белье (всех веб-фреймворков). Несмотря на то, что жертвой был Oracle Apex, то же самое могло произойти с .net или j2ee, если бы споры велись между гуру .net и j2ee. Я считаю, что у всех фреймворков есть свои плюсы и минусы. Вот почему на самом деле у нас их так много. Спорить о том, что для жизни важнее (секс, еда или вода?) - пустая трата времени. Естественно, мы выбираем наиболее подходящий элемент, когда это необходимо.

• Пакет Oracle APEX для сред, в которых имеется много баз данных Oracle и когда у вас действительно есть энтузиасты Pl / SQL. Можно действительно легко создавать многофункциональные, сложные приложения Web 2.0 Data Centric (Apex 4.0), но отладка и контроль версий по-прежнему представляют собой беспорядок, и вам также придется придерживаться базы данных Oracle (да, у вас могут быть обходные пути но не надежный).