Caché + Java + Flex. Особенности интеграции технологий. Часть 3

[veitmen]

Добрый день.

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

Зачем использовать Cach'e? Ведь каше не самая лучшая СУБД. Она показывает всю силу, если вы используете CacheScript и не забываете про глобаллы.

Насколько оправданно использование агентов? Неужели нельзя было решить задачу на стороне Cach'e? После чего реализовать ряд SOAP сервисов на стороне Cach'e и дергать их из флекса. Благо каше умеет создавать SOAP сервисы, а на стороне флекса можно генерить прокси классы по WSDL.

Ну и собственно почему именно Cach'e + java + flex? Три больших технологии, которые при разработке надо знать. Более того, Cach'e, не самая распространенная технология на нашем рынке, а flex то уже отмирает. Чем обусловлен этот выбор? Ну кроме того, что если мы используем Cach'e, нас поощряет InterSystems?

[yakuninyy]

Зачем использовать Cach'e?

Это представитель объектной СУБД, в которой генерируются проекции на java, что позволяет реализовать объектную связку с java-классами нашей системы. Какие ещё есть кандидаты с таким функционалом?

Насколько оправданно использование агентов? Неужели нельзя было решить задачу на стороне Cach'e? После чего реализовать ряд SOAP сервисов на стороне Cach'e и дергать их из флекса.

Тогда нам бы пришлось написать на Cache мультиагентную платформу аналогичную JADE в соответствие со стандартом FIPA. Использование мультиагентной платформы обусловлено сложностью задачи. В комментариях к первой части объясняются причины выбора мультиагентного подхода.

Ну и собственно почему именно Cach'e + java + flex? Три больших технологии, которые при разработке надо знать. Более того, Cach'e, не самая распространенная технология на нашем рынке, а flex то уже отмирает. Чем обусловлен этот выбор? Ну кроме того, что если мы используем Cach'e, нас поощряет InterSystems?

Не всегда распространённость технологии говорит о её преимуществах и является критерием её выбора. В нашей организации есть лицензия на Cache и разработаны некоторые системы, также используются и другие технологии и СУБД. Здесь Cache была выбрана из-за её объектности и java-проекций, не считая других её качеств как СУБД.
Что касается flex, то здесь не всё так однозначно, возможно другие модули системы уже будут реализовываться на HTML5.

[morisson]

Зачем использовать Cach'e? Ведь каше не самая лучшая СУБД.

Обычно говорят «СУБД плохая» если не получается сделать что-то определенное, или существует совершенно конретная проблема, которую не удалось решить с помощью СУБД. Посему вопрос — а что не получилось сделать?

[veitmen]

Это представитель объектной СУБД, в которой генерируются проекции на java, что позволяет реализовать объектную связку с java-классами нашей системы.

Ну не объектной, а постреляционной (или что то изменилось?). В полной мере наследование лучше не использовать. Т.к. оно сделано через одно место. Будет создаваться две сущности (не помню уже как там конкретно в терминах на уровне Cach'e), со связями один к одному. В общем то, что вы видите объектное представление, не есть в полной мере объектное представление на уровне хранения данных. Отсюда следует что используя любую ORM над реляционной СУБД, вы получите ровно тот же функционал. Но раз мы уж говорим о объектах на уровне СУБД, то какая часть функционала вынесена в эти объекты? Так ли вам нужны объекты на уровне СУБД? Или вам будет, опять таки, достаточно объектного представления реляционной модели?

Тогда нам бы пришлось написать на Cache мультиагентную платформу аналогичную JADE в соответствие со стандартом FIPA.

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

Но как я уже говорил, не понятно зачем такой зоопарк технологий. Если уж вам так важно использовать каше, то может лучше реализовать часть функционала (самое необходимое) Jade на стороне Cach'e? Да, это велосипед, который позволяет полностью отказаться от использования лишней технологии! Мне кажется игра стоит свеч! Ведь проще будет погружаться и система станет проще. Но скорее всего, я бы пришел к выводу, что Cach'e есть лишняя технология. Объектное представление данных вам даст любая ORM технология.

[yakuninyy]

Ну не объектной, а постреляционной (или что то изменилось?).

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

В полной мере наследование лучше не использовать. Т.к. оно сделано через одно место. Будет создаваться две сущности (не помню уже как там конкретно в терминах на уровне Cach'e), со связями один к одному.

Создадутся две таблицы в реляционном представлении. Но все данные хранятся в разреженных многомерных массивах. И в случае создания и сохранения объектов класса наследника, в БД создастся один глобал, а не два, но в реляционном виде будет две таблице, в одной из которых появится несколько записей по числу сохранённых объектов.

Но раз мы уж говорим о объектах на уровне СУБД, то какая часть функционала вынесена в эти объекты? Так ли вам нужны объекты на уровне СУБД? Или вам будет, опять таки, достаточно объектного представления реляционной модели?

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

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

О каком готовом решении для нашей задачи идёт речь?

Если уж вам так важно использовать каше, то может лучше реализовать часть функционала (самое необходимое) Jade на стороне Cach'e?

Может в этом и есть какой-то смысл, но на это точно нет ресурсов.

Но скорее всего, я бы пришел к выводу, что Cach'e есть лишняя технология. Объектное представление данных вам даст любая ORM технология

А любая другая реляционная СУБД с ORM надстройкой лишней технологией уже являться не будет?

[veitmen]

О каком готовом решении для нашей задачи идёт речь?

Я имел ввиду JADE.

А любая другая реляционная СУБД с ORM надстройкой лишней технологией уже являться не будет?

Да, наверное я не верно употребил термины. Не технология, а платформа лишняя. Cach'e или java мне кажутся лишними. ORM будет новой технологией, но не платформой. Просто это совсем другой уровень. ORM будет написан на java и будет использовать примочки именно этой платформы. СУБД как платформу я думаю рассматривать глупо, не будете же вы туда логику выносить, в процедуры. У вас же получается используются три платформы, для решения задачи. Когда достаточно двух. А то и одной джавы.

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

[DAiMor]

Ну не объектной, а постреляционной (или что то изменилось?). В полной мере наследование лучше не использовать. Т.к. оно сделано через одно место.

А чем не нравится объектная модель в Cache'?
И что не так с наследованием. Что я делаю не так, что не вижу проблем?