Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 52
забракат!
И хрюкотали зелюки, как мюмзики в маве...(Л. Кэрролл) Простите, но такие ассоциации с вашим комментарием ;)
Вот мне всегда было интересно, а почему вот это «хабракат!» надо обязательно писать в комментариях? Что, никак нельзя зайти в свои сообщения (%username%.habrahabr.ru/mail) и нажать ссылку «написать»?
на одном из проектов применяли следующий подход.
Было написано базовое приложение состоящее из множества maven модулей. На выходе получался war'ник с кучей jar'ников внутри. В дальнейшем дописывались новые maven модули, которые либо замещали существующую функциональность, либо дополняли. Дальше, с помощью мавен-плагина Carge, war'ник базового проекта мёржился с war'ником конкретной надстройки, в результате получался war'ник, в котором было всё из общего приложения, плюс некоторые jar'ники были заменены новыми.
Было написано базовое приложение состоящее из множества maven модулей. На выходе получался war'ник с кучей jar'ников внутри. В дальнейшем дописывались новые maven модули, которые либо замещали существующую функциональность, либо дополняли. Дальше, с помощью мавен-плагина Carge, war'ник базового проекта мёржился с war'ником конкретной надстройки, в результате получался war'ник, в котором было всё из общего приложения, плюс некоторые jar'ники были заменены новыми.
сори, плагин называется Cargo
Интересное решение 8)
А насколько мелкие jar-ники были? Получается, что надо делать очень маленькие библиотеки, чтобы при необходимости можно было их заменять?
А насколько мелкие jar-ники были? Получается, что надо делать очень маленькие библиотеки, чтобы при необходимости можно было их заменять?
да, джарники весьма маленькие. Всего в базовом приложении было около 30-40 jar'ников (не включая стандартные или 3rd-party)
был еще более сложный и специфичный подход, который долго объяснять, поэтому всего в двух словах:
точно так же написано базовое приложение, в котором куча jar'ников. В каждом jar'нике есть некий файл product.context, в котором хранится значение product=BASE.
В тех jar'никах, которые должны заменить существующие из базового проекта, эта переменная выставлялась в новое значение product=APP1.
Приложение написано на Spring'e + JSF. Для подгрузки подходящего JSF ресурса был написано ResourceResolver, который в зависимости от контекста приложения доставал либо базовый, либо кастомизированный ресурс. То же самое с бинами из Spring — был переопределён BeanLoader, который в зависимости от контекста доставал нужные бины, определённые либо в базовом, либо в кастомизированном приложении.
Этот вариант позволял делать кастомизацию с несколькими уровнями, например APP1 кастомизировал BASE, а APP2 кастомизировал уже APP1
Извините если непонятно написал:)
точно так же написано базовое приложение, в котором куча jar'ников. В каждом jar'нике есть некий файл product.context, в котором хранится значение product=BASE.
В тех jar'никах, которые должны заменить существующие из базового проекта, эта переменная выставлялась в новое значение product=APP1.
Приложение написано на Spring'e + JSF. Для подгрузки подходящего JSF ресурса был написано ResourceResolver, который в зависимости от контекста приложения доставал либо базовый, либо кастомизированный ресурс. То же самое с бинами из Spring — был переопределён BeanLoader, который в зависимости от контекста доставал нужные бины, определённые либо в базовом, либо в кастомизированном приложении.
Этот вариант позволял делать кастомизацию с несколькими уровнями, например APP1 кастомизировал BASE, а APP2 кастомизировал уже APP1
Извините если непонятно написал:)
сдается мне, что вы неправильно понимаете термин monkey-patching.
Весь (практически) код приложения создаётся для приложения в начале разработки автоматически (скриптом, батником, архетипом и тп) а в последствии изменяется под свои нужды в каждом конкретном проекте.
Примером такого подхода являются большинство фреймворков на динамических ЯП: ruby on rails, django, grails
ОМГ, про grails и RoR не скажу, но Django вы сюда точно зря приписали. Там полным ходом используются pluggable applications. Некоторые из них распространяются с самим Django: админка, система аутентификации, комментарии, и т.п.
А ещё и судя по тому, что вы написали про monkey-patching, про RoR и grails тоже не совсем правда написана. Что вызывает некоторые сомнения про весь остальной текст.
appfuse генерит много ненужного кода и всяких левых зависимостей.
да, все это отключается, но в чем тогда смысл? в общем, штука полезная для ознакомления с веб-приложениями, но использовать его постоянно для себя нет смысла — проще брать скелет какого-то своего обкатанного приложения.
ну и вообще, оно предлагает поддержку только action framework, а сейчас народ все больше делает нервные движения в сторону ухода к component frameworks… опять же, для богато-аяксового приложения особой помощи appfuse не делает.
Полагаю, после пары лет дальнейшей эволюции и обкатки яваскриптовых библиотек виджетов, это направление вообще отомрет, и веб разработка будет в основном делаться в стиле GUI приложений. А сгенерить по нескольким классам-сущностям hibernate-DAO много ума не надо.
да, все это отключается, но в чем тогда смысл? в общем, штука полезная для ознакомления с веб-приложениями, но использовать его постоянно для себя нет смысла — проще брать скелет какого-то своего обкатанного приложения.
ну и вообще, оно предлагает поддержку только action framework, а сейчас народ все больше делает нервные движения в сторону ухода к component frameworks… опять же, для богато-аяксового приложения особой помощи appfuse не делает.
Полагаю, после пары лет дальнейшей эволюции и обкатки яваскриптовых библиотек виджетов, это направление вообще отомрет, и веб разработка будет в основном делаться в стиле GUI приложений. А сгенерить по нескольким классам-сущностям hibernate-DAO много ума не надо.
мы сделали так
xslt решает все проблемы с view-слоем
в качестве framework для подключаемых модулей используем jpf.sourceforge.net, очень крутая штука, рекомендую
xslt решает все проблемы с view-слоем
в качестве framework для подключаемых модулей используем jpf.sourceforge.net, очень крутая штука, рекомендую
Если речь идет о небольших изменениях/отклонениях (пример с магазином), то аспекты вам в помощь.
Как вариант стоит рассмотреть, но в большом проекте я боюсь, что аспекты черезчур усложнят разработку.
Зависит от того, что такое для вас «большой проект», какие изменения в функционале требуются и насколько грамотно построена архитектура самого приложения.
У меня есть достаточно положительный опыт использования аспектов в приложении среднего размера (АРМ для обработки заявок на АДСЛ подключения).
У меня есть достаточно положительный опыт использования аспектов в приложении среднего размера (АРМ для обработки заявок на АДСЛ подключения).
согласен с каждым словом, как высвободится немного времени попробую решить проблему аспектами 8)
какие аспекты были, кроме элементарных логгирования, аутентификации и транзакций?
Где то выше уже говорилось о Spring. Крайне советую обратить на него внимание. Это IOC для того того и был придуман чтобы подставлять в нужные места классы с нестандартной функциональностью не основной код.
Спринг — замечательный фреймворк, но все потребности «плагинистости» он не покрывает. В частности я незнаю как с его помощью можно запихнуть в либу интерфейс страницы, а потом в проекте частично его изменить.
>запихнуть в либу интерфейс страницы
oh noes
make me unsee it
oh noes
make me unsee it
селяви %)
А какие есть варианты? Копи-пастить страницы из проекта в проект?
а что у вас за проекты? типичный use-case хранения страницы в библиотеке не приведете?
жжоте
что-то надо править в консерватории
что-то надо править в консерватории
Не совсем понял о чём Вы?
он о том, что хранить в либе страницы это как-то странновато
ну, по реплике «Копи-пастить страницы из проекта в проект?» я догадался, что bmc хочет реюзабельных законченных UI компонентов.
Мне кажется, что это не всегда так.
К примеру, говоря о JSF и Facelets: вполне легальным случаем использования является хранение параметризуемых частей XHTML-страниц в библиотеках. Это, конечно, не дает возможности полностью избежать копи-паста, но, тем не менее, существенно сокращает количество кода, повторяющегося из проекта в проект. Характерный пример — функциональность login/logout.
К примеру, говоря о JSF и Facelets: вполне легальным случаем использования является хранение параметризуемых частей XHTML-страниц в библиотеках. Это, конечно, не дает возможности полностью избежать копи-паста, но, тем не менее, существенно сокращает количество кода, повторяющегося из проекта в проект. Характерный пример — функциональность login/logout.
в рамках вашего подхода проблема вообще вряд ли решается.
посмотрите на компонентный подход:
echo.nextapp.com/site/
www.zkoss.org/
wicket.apache.org/
посмотрите на компонентный подход:
echo.nextapp.com/site/
www.zkoss.org/
wicket.apache.org/
Общего решения, к сожалению не существует. В зависимости от размера проекта (как по количеству кода, так и по количеству разработчиков) применимы разные подходы.
На практике использование только Equinox на производительности сказывается немного. Другое дело, что сам по себе Equinox особо удобно не поиспользуешь — слишком много кода для интеграции приходится писать. Частым вариантом является связка Equinox + Spring Dynamic Modules + Spring Framework. И вот здесь уже понятно, что работает это все довольно медленно. К сожалению, потому что концептуально все выглядит неплохо.
скорость (при использовании такой прослойки как equinox все операции взаимодействия между модулями приложения будут по определению медленнее, чем без использования такой прослойки. Насколько это замедляет приложение на практике сказать сложно — необходимо тестирование).
На практике использование только Equinox на производительности сказывается немного. Другое дело, что сам по себе Equinox особо удобно не поиспользуешь — слишком много кода для интеграции приходится писать. Частым вариантом является связка Equinox + Spring Dynamic Modules + Spring Framework. И вот здесь уже понятно, что работает это все довольно медленно. К сожалению, потому что концептуально все выглядит неплохо.
О Рельсах немного неправду сказали вы.
Сами Rails хранятся в библиотеке Ruby как Gem (модуль, плагин, jar, как вам будет понятнее). На этапе создания приложения скрипт генерирует скелет, который использует эти основные библиотеки, при чем использует довольно активно. Затем программист уже на основе этого скелета выстраивает своё приложение. Convention over Configuration, и всё такое.
После обновления ядра RoR ваше приложение при следующей загрузке подхватит обновленные библиотеки. Максимум, что придется сделать — это, возможно, изменить где-то в приложении участок кода для лучшей совместимости, или убрать старые костыли.
И даже этого можно избежать, «заморозив» приложение (rake rails: freeze) — оно будет всё время использовать одну и ту же версию Rails-библиотек, независимо от того, до какой версии вы обновите у себя Rails.
Сами Rails хранятся в библиотеке Ruby как Gem (модуль, плагин, jar, как вам будет понятнее). На этапе создания приложения скрипт генерирует скелет, который использует эти основные библиотеки, при чем использует довольно активно. Затем программист уже на основе этого скелета выстраивает своё приложение. Convention over Configuration, и всё такое.
После обновления ядра RoR ваше приложение при следующей загрузке подхватит обновленные библиотеки. Максимум, что придется сделать — это, возможно, изменить где-то в приложении участок кода для лучшей совместимости, или убрать старые костыли.
И даже этого можно избежать, «заморозив» приложение (rake rails: freeze) — оно будет всё время использовать одну и ту же версию Rails-библиотек, независимо от того, до какой версии вы обновите у себя Rails.
Ну так вот человек хочет иметь не просто скелет в базовой поставке, а ещё пару моделей-контроллеров. В Django это реализованно с помощью приложений. В Rails этого нет, есть вроде костыль в виде Rails-Engines, но DHH против этого, так что в корке этого нет и не будет.
Ключевые слова: Plugins и Gems
Плагины и гемы тоже умеют «делать» генераторы и расширять базовый функционал, с помощью которых человек в итоге может сгенерировать какой угодно скелет. Обновление плагинов так же просто, как и гемов — checkout с репозитория, и у тебя последняя версия плагина или гема, и никакого Monkey-patching'а.
Рекомендую посмотреть на Radiant, как довольно интересный пример. Целая CMS в виде Gem'а, которая обновляется так же легко, как и ядро: gem update. И всё.
Хотя я может чего-то и недопонимаю, т.к. не работал с Django.
Что, по вашему, нельзя сделать в рельсах такого, что не требовало бы monkey-patching'а?
Плагины и гемы тоже умеют «делать» генераторы и расширять базовый функционал, с помощью которых человек в итоге может сгенерировать какой угодно скелет. Обновление плагинов так же просто, как и гемов — checkout с репозитория, и у тебя последняя версия плагина или гема, и никакого Monkey-patching'а.
Рекомендую посмотреть на Radiant, как довольно интересный пример. Целая CMS в виде Gem'а, которая обновляется так же легко, как и ядро: gem update. И всё.
Хотя я может чего-то и недопонимаю, т.к. не работал с Django.
Что, по вашему, нельзя сделать в рельсах такого, что не требовало бы monkey-patching'а?
1 — grails, 3 — ручками
Есть еще такая вещь как Model Driven Architekture & Model Driven Development. Тут смысл не в рисовании UML-моделей на стадии «конципирования» а создании собственных, т.н. спецефических языков предметной области (domain specific language), использующие конкретную предметную область для моделирования приложения по принципу метамодель->тех. независимая модель->трансформация->тех. зависимая модель->генерация->готовый код.
В данном случае «тиражирование» и «дополнение/изменение» находится на модельном уровне + создании/изменении генераторов или трансформаторов.
вот довольно распространенные ОС инструменты из этой области
www.andromda.org
www.openarchitectureware.org
мне лично очень нравится oaw, позволяющий работать с текстовыми моделями (хТехт) с помощью самодельных редакторов -> они (модели) намного легче читаются чем UML, легко сравниваются, изменения понятны и вообще, крутая вещь:)
В данном случае «тиражирование» и «дополнение/изменение» находится на модельном уровне + создании/изменении генераторов или трансформаторов.
вот довольно распространенные ОС инструменты из этой области
www.andromda.org
www.openarchitectureware.org
мне лично очень нравится oaw, позволяющий работать с текстовыми моделями (хТехт) с помощью самодельных редакторов -> они (модели) намного легче читаются чем UML, легко сравниваются, изменения понятны и вообще, крутая вещь:)
Старый добрый ООП для business layer-а еще никто не отменял. Достоинство: на основе написанных компонентов при минимальном изменении можно кастомизировать логику. Недостаток: усложняется инъекция новых объектов, решается при помощи фреймворков типа Spring.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
тиражируемые решения