LINUX.ORG.RU
ФорумTalks

Энтерпрайз ERP/CRM фо отомейшн оф ё сириоз бизнес

 , , ,


6

2

ERP-шники из прошлого треда сдулись, а мой интерес к вопросу только разгорелся. Моя попытка нарыть что-то более-менее объемное по теме создает ощущение, что ERP — это как онанизм: все занимаются, но никто не обсуждает. Нашел забавную статью на хабре:

https://habr.com/en/post/447162/ - Не купитесь на ERP

Сразу скажу, что я не согласен с автором, но позиция интересна. Если слегка смягчить ее, то получится что-то такое: если на вашем предприятии бардак, то ERP за вас не сможет его организовать; если же вы навели порядок на своем предприятии, то ERP вам уже особо и не нужна.

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

Подход SAP в этом плане весьма остроумен с коммерческой точки зрения, потому что работы по сверхточному нанесению пользы сам SAP не выполняет, вместо этого клепая вот такие таблички на 240 столбцов:

https://www.sapdatasheet.org/abap/tabl/mara.html

Ну или просто позволяя вам выбрать из готового набора 110 000 (сто десять тысяч) табличек те, которые подойдут вашему бизнесу... или не подойдут. Остроумен с коммерческой точки зрения такой подход потому, что с позиции человека, который не разбирается в IT, то есть, типового клиента SAP, какой-нибудь SAP R/3 предоставляет собой крупную хорошо проработанную и проверенную систему, которая покрывает чуть ли не все на свете варианты бизнес-процессов предприятия. В такие моменты я люблю вспоминать покойного Дейкстру:

“Simplicity is a great virtue but it requires hard work to achieve it and education to appreciate it. And to make matters worse: complexity sells better.”

То есть, приходит менеджер, который отвечает за принятие решений, и спрашивает у продажника SAP: «у вас есть ${фичанейм} в системе? Насколько хорошо автоматизирует ${процесснейм} ваше решение?». Причем, говорить об этом до начала внедрения — это все равно, что спрашивать у женщины «вы можете родить мальчика или девочку? А мальчик будет гениальным?». Особенно если этой женщине 50 лет и ее маркетинговое преимущество — это что оба ее сына стали успешными учеными.

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

Пока что, из моего опыта разработки CRM/недо-ERP, мне видится, что одно из ключевых препятствий на пути заполнения данной ниши — это реляционные СУБД, которые используется к месту и не к месту — просто потому, что РСУБД есть готовые в большом количестве. Как правило, даже у достаточно конкретного клиента есть ни разу не конкретные требования по автоматизации, которые меняются день ото дня, вроде «мы узнали длину члена Василия Петровича — давайте сохраним эту информацию в CRM записи про Василия Петровича, в надежде, что со временем удастся собрать аналогичные сведения по другим клиентам и вывести кореляции». Происходит это не только из-за сиюминутных прихотей конкретного менеджера, но и из-за постепенной смены коньюктуры и технологий в фирме.

Реляционная же модель приводит к тому, что когда внезапно появляется необходимость сделать связь сущностей N-к-M вместо какой-нибудь 1-к-N, то приходится перекраивать базу верх ногами, создавая новую таблицу связей между сущностями и изменяя алгоритмы создания-чтения-обновления-удаления. А в случае перехода от 1-к-1 в N-к-M нужно создавать уже две дополнительные таблицы. У того же SAP по этому поводу из коробки для целой кучи атрибутов есть поддержка множественных связей, откуда и появилось астрономическое количество табличек — в реальности таблиц корневых сущностей там всего несколько сотен.

Апгрейды, поддержка, доработка — это, между прочим, основной доход вышеупомянутой SAP. Моя воображаемая цель проста: уничтожить SAP с ораклом. По крайней мере, такова она по состоянию на момент создания треда.

Есть много опенсорсных попыток писания ERP софта (например, Odoo, OpenERP, IDempiere/Compiere/Adempiere/Openbravo/metasfresh), но каждая из них, как правило, представляет собой одну и ту же попытку повторить SAP в мелком масштабе. У меня есть некоторые абстрактные зарисовки по этой теме, но, как показывает практика, публиковать их не имеет смысла, а пытаться сделать что-то конкретное прямо сейчас у меня тупо нет времени/желания, поскольку я работаю над релизом предыдущего незаконченного проекта питоньей многозадачности. Так что принимайте эстафету.

★★★★

Ответ на: комментарий от sanyo1234

А что мешает сжимать данные на диске? Db2 сама умеет, кто не умеет, для тех есть файловые системы со сжатием, например ZFS

Я боюсь, что из-за проблем с производительностью пакования это превратится в популярное нынче «полный снимок базы по таймеру». Потому что, как правило, нельзя просто взять и записать страницу жатых данных на диск по первому требованию.

byko3y ★★★★
() автор топика
Последнее исправление: byko3y (всего исправлений: 1)
Ответ на: комментарий от sanyo1234

Приложение -> Hibernate -> distributed Hibernate cache (Tarantool cluster) -> классическая РСУБД типа Db2/PG

Зачем столько звеньев? Как будет инвалидироваться кэш?

byko3y ★★★★
() автор топика
Ответ на: комментарий от foror

Вот это всё клоунада, зажрался наш илоний маск

Ты так пишешь, будто он еще 17 лет назад не зажрался.

byko3y ★★★★
() автор топика
Ответ на: комментарий от sanyo1234

Тогда, может быть, сделаешь сразу как у DevExpress XAF?

Много лет работал с DevExpress. Там сидят конченные эффективные манагеры с архитектурой и диаграммами головного мозга в терминальной стадии. Да, у них откуда-то есть чудовищное количество ресурсов для того, чтобы этого спагетти-монстра заставлять работать, и все равно количество багов зашкаливает (я подпер костылями и исправил около десятка в их компоненте табличного отображения) — и их будет еще больше с изменением и наращиванием функциональности, потому что это неизбежное свойство спагетти-кода.

Чтобы с редактором модели (как в 1Це) и автоматическим обновлением структуры базы и ORM классов

Красивые редакторы моделей с рюшечками не решают фундаментальной проблемы — они просто позволяют секретарше не испугаться и все-таки освоить инструмент. Но по мере роста секретарша неизбежно упрется в ограниченность «инструмента для тупых».

byko3y ★★★★
() автор топика
Ответ на: комментарий от sanyo1234

Это конечно так, но IMHO масштабировать L2 Cache в кластере типа Tarantool проще, чем РСУБД?

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

byko3y ★★★★
() автор топика
Ответ на: комментарий от byko3y

А что посоветуешь лучше, чем DevExpress?

У какого-то вендора есть более продуманная объектная модель для WinForms, чем у девок?

Да и XAF вроде бы неплох на первый взгляд, я пока только изучаю его. Других аналогов XAF я вообще не знаю, чтобы все в одном :(

sanyo1234
()
Последнее исправление: sanyo1234 (всего исправлений: 2)
Ответ на: комментарий от byko3y

Там же всю логику нужно будет руками писать.

Там - это где? В Хибере?

Тарантул разве масштабируется не прозрачно для приложения?

sanyo1234
()
Ответ на: комментарий от byko3y

Зачем столько звеньев?

А как сделать меньше, чтобы при этом с одной стороны был ORM, а с другой осталась РСУБД?

Как будет инвалидироваться кэш?

Я думал, есть готовые решения для Hibernate?

sanyo1234
()
Ответ на: комментарий от foror

ORM не нужна, ее подобие должно быть встроено в СУБД, чтобы не заморачивать пользователей лишними сущностями. Именно поэтому плотная интеграция в JVM

Проблема модели данных JVM заключается в том, что они не удобны ни компьютеру. ни человеку. Манагеры Sun выбрали худший вариант из доступных, короче говоря. Машине нужны сплошные однообразные массивы, человеку нужны гибкие осмысленные структуры, сами адаптирующиеся под задачу — классы являются не гибкими и не однообразными. Потому высокопроизводительные вычисления на JVM возможны только на массивах, но в чистой Java работать с массивами очень больно и унизительно.

byko3y ★★★★
() автор топика
Ответ на: комментарий от byko3y

Потому высокопроизводительные вычисления на JVM возможны только на массивах

Можно пруфы?

но в чистой Java работать с массивами очень больно и унизительно.

Это почему и по сравненинию с чем (в смысле non JVM)?

sanyo1234
()
Последнее исправление: sanyo1234 (всего исправлений: 1)
Ответ на: комментарий от foror

Не знаю, на офтопике я только с SOLIDWORKS работаю, ибо аналоги на линуксе совсем уж детские поделки. Но сама идея GUI редактора для модели выглядит ущербно

OLOLO, при чем тут солидворкс, моделирующий физические тела, к ORM для БД? Если художник рисует картину, то ему удобнее это делать в графическом редакторе, естественно. Если же речь заходит про обработку текста — зачем тут графическое (нетекстовое) отображение? Вот если нужно строить статистические графики по данным из БД — тогда, опять-таки, нужна графика. Если нужно вставить одну запись в БД — графика снова не нужна.

byko3y ★★★★
() автор топика
Ответ на: комментарий от sanyo1234

А что посоветуешь лучше, чем DevExpress?
У какого-то вендора есть более продуманная объектная модель для WinForms, чем у девок?

Если у вашего проекта есть хотя бы пару человеколет, то, как правило, все фичи вы можете реализовать на простейших универсальных и компонентах отображения и пользовательского ввода. Потому что неизбежно выяснится, что стандартная логика вам не подходит, как и стандартный вид онной аля «клон SAP», а переделывание этой лапши займет столько сил, что проще было бы сделать с нуля сразу под ваши требования. Ровно в такую же западню попал SAP — но он и хотел в нее попасть, судя по всему, ему там вполне удобно.

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

Вот именно, что «всё в одном» лучше продается. Это уже после того, как его покупают, самые сообразительные понимают, что это дикий vendor-lock, расширять сторонними компонентами который нецелесообразно (слишком трудоемко), ровно как и чудовищно тяжело его дорабатывать/перерабатывать. Добавление какой-то небольшой фичи или перерабатывание поведения в не предусмотренном заранее разработчиками направлении растягивается на месяц-другой, а потом еще и всплывают неожиданные баги спустя месяцы, в том числе в виде скрытых багов в самом DevExpress.

byko3y ★★★★
() автор топика
Ответ на: комментарий от sanyo1234

Тарантул разве масштабируется не прозрачно для приложения?

Он, может быть, и масштабируется прозрачно, но он изначально не является прозрачным кэшем. Синхронная репликация «в лоб», которая как бы самая прозрачная, одновременно и самая медленная. Потому в тарантуле есть опция асинхронной репликации, которая используется по умолчанию, но она не прозрачна, поскольку при отказе что-то потеряется — этот сценарий нужно будет как-то прорарабывать. Я понимаю, что большинство BigData-школьников скажут «да пофигу, прорвемся», как это и делается в большинстве коммерческих систем — но мы не из таких, мы помним, что значит буква D в аббревиатуре ACID, и чем вообще отличается СУБД от беспорядочно скидываемых на диск данных с наколеночным индексом — что, вообще-то, можно реализовать за неделю-другую при отсутствии требований распределенности.

byko3y ★★★★
() автор топика
Ответ на: комментарий от byko3y

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

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

DevExpress XAF позволяет клепать true ООП формошлепные редакторы приложений за несколько дней, а не лет.

sanyo1234
()
Последнее исправление: sanyo1234 (всего исправлений: 1)
Ответ на: комментарий от sanyo1234

А как сделать меньше, чтобы при этом с одной стороны был ORM, а с другой осталась РСУБД?

Ты подразумеваешь, что ORM — это совершенное добро, как и РСУДЬ. Я не согласен с обоими тезисами.

byko3y ★★★★
() автор топика
Ответ на: комментарий от byko3y

Ты подразумеваешь, что ORM — это совершенное добро, как и РСУДЬ

Вовсе нет, просто я к ним привык, пока не хочу изучать всякие Cassandra и т.п.

А от InterSystems Cache так вообще осталось только негативное впечатление.

sanyo1234
()
Последнее исправление: sanyo1234 (всего исправлений: 1)
Ответ на: комментарий от sanyo1234

Потому высокопроизводительные вычисления на JVM возможны только на массивах

Можно пруфы?

Тебе бенчи или как? Суть в том, что JVM может хранить примитивные типы, вроде чисел, без контейнеров и косвенной адресации прямо в массиве. Оно же Structure of Arrays — кортеж массивов. Таким образом массив станет одной сущностью для сборщика мусора, и итерирование по этому массиву будет происходит без разыменования дополнительных указателей. То есть, сразу два источника тормозов JVM исключаются из уравнения.

Очевидная проблема этого подхода — ты можешь иметь только примитивные типы данных в массиве. Чтобы найти соответствующие значения записи из разных столбцов, нужно найти позицию отдельно в каждом массиве. Эдакая колоночная СУБД.

Это почему и по сравненинию с чем (в смысле non JVM)?

Да хотя бы в сравнении с Хаскелем или Clojure, где можно наклепать удобные и комбинируемые абстракции над низкоуровневым механизмом.

byko3y ★★★★
() автор топика
Ответ на: комментарий от sanyo1234

DevExpress XAF позволяет клепать true ООП формошлепные редакторы приложений за несколько дней

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

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

Ты отвечал по поводу проекта более-менее универсальной СУБД для публичного пользования — вот я тебе и отвечаю про публичный софт, для которого DevExpress не подходит, потому что багованный и нерасширяемый.

byko3y ★★★★
() автор топика
Ответ на: комментарий от sanyo1234

А от InterSystems Cache так вообще осталось только негативное впечатление

О, это же MUMPS. Расскажи, как впечатление-то, поподробнее, какие основные минусы и плюсы, что больше всего испортило «впечатление». А то тут забегал поехавший, который рекламировал свою MUMPS-производную поделку, и в упор отрицал очевидные проблемы этого решения плана «на каждый запрос нужно с нуля писать свою собственную СУБД».

byko3y ★★★★
() автор топика
Ответ на: комментарий от byko3y

Да, и больше ни для чего другого он не подходит.

Так XAF мне собственно и нужен в качестве аля MS Access или PowerBuilder для скоростного формошлепства настроек конфигов для деплоя.

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

Ну так десктопные формочки, но и есть возможность рендерить их на http сервере.

а последний разработчик, который знал, как оно устроено, уволился из компании 2 года назад.

Ты про компанию DevExpress?

sanyo1234
()
Ответ на: комментарий от byko3y

Потому высокопроизводительные вычисления на JVM возможны только на массивах, но в чистой Java работать с массивами очень больно и унизительно.

Поэтому изначально была идея пилить новый ЯП с гибридной системой управления памятью (без GC) и встроенной IDE. Но прикинув все за и против (в том числе уходящие года) - решил пока остаться на JVM. Тем более ForeignMemory впилили, Valhalla на подходе, что уменьшит боль выжимания перформанса из JVM. Плюс на край есть Graal Native.

foror ★★★★★
()
Последнее исправление: foror (всего исправлений: 1)
Ответ на: комментарий от byko3y

Ты так пишешь, будто он еще 17 лет назад не зажрался.

Нормальный чувак, не завидуй. Лучшее из худших.

foror ★★★★★
()
Ответ на: комментарий от byko3y

О, это же MUMPS.

Я его только админил одно время, очень тошнотворный интерфейс (даже CLI) по сравнению с любой известной мне СУБД.

Видел скрипты, это жуть, синтаксис Brainfuck в профиль.

Разрабы постоянно косячили, то у них задвоения данных, то вообще запятерение, то таблицы из внешней СУБД не синхронизируются, - рецепт разработчиков - переустановите Cache, самый жуткий период моей жизни (в смысле используемой СУБД), когда мне пришлось прикасаться к этому Г.

Даже не исключаю, что в ядре Cache заложены какие-то хорошие идеи объектной СУБД, но реализация IMHO просто ужасная.

И ведь есть немало других вариантов, вероятно среди них есть что-то и получше:

https://en.wikipedia.org/wiki/Object_database

Вероятно качество кастом разработки и их инструкции по решению проблем синхронизации по крайне мере первое время были тоже не ахти.

sanyo1234
()
Последнее исправление: sanyo1234 (всего исправлений: 4)
Ответ на: комментарий от sanyo1234

Так XAF мне собственно и нужен в качестве аля MS Access или PowerBuilder для скоростного формошлепства настроек конфигов для деплоя

Так используй MS Access и PowerBuilder.

а последний разработчик, который знал, как оно устроено, уволился из компании 2 года назад.

Ты про компанию DevExpress?

Я про фирму, которая на базе DevExpress разрабатывала продукт для внутреннего пользования.

byko3y ★★★★
() автор топика
Ответ на: комментарий от sanyo1234

Даже не исключаю, что в ядре Cache заложены какие-то хорошие идеи объектной СУБД, но реализация IMHO просто ужасная

Ну да, MUMPS, совместимость с совместимостью — есть такое. Cache уже сильно позже «развития» этой технологии сделали. Изначально это Г. интерпретировало каждый символ как команду, а скукоживали программу потому, что было очень мало памяти.

byko3y ★★★★
() автор топика
Ответ на: комментарий от byko3y

Так используй MS Access и PowerBuilder.

Использую Libre Base, но также как и MS Access он слишком ограничен в своих возможностях, невозможно расширять объектную модель графической части, нет интеграции с ORM, поэтому приходится вручную прикручивать DevArt Entity Developer:

https://www.devart.com/entitydeveloper/nhibernate-designer.html

Кроме того usability DevExpress на голову выше и есть возможность автоматически переключить GUI из десктопного WinForms например на web server-side Blazor.

sanyo1234
()
Последнее исправление: sanyo1234 (всего исправлений: 6)
Ответ на: комментарий от byko3y

Ну да, MUMPS, совместимость с совместимостью — есть такое. Cache уже сильно позже «развития» этой технологии сделали. Изначально это Г. интерпретировало каждый символ как команду, а скукоживали программу потому, что было очень мало памяти.

Сразу бы делали в машинных кодах, зачем нам эти буржуазные изыски с красивым и понятным синтаксисом как в других СУБД, ORM, ЯП.

Мало того что в InterSystems Cache через одно место сделана обвязка их теоретически неплохого ядра, так они еще пытались сделать «все в одном», т.е. чуть ли не ось в оси, и все через тоже самое одно место.

sanyo1234
()
Последнее исправление: sanyo1234 (всего исправлений: 1)
Ответ на: комментарий от byko3y

Я про фирму, которая на базе DevExpress разрабатывала продукт для внутреннего пользования.

Кого волнуют проблемы недовасянов?

sanyo1234
()
Ответ на: комментарий от sanyo1234

Кстати по теме вашей ветки о ERP-ах, есть как минимум одна на базе DevExpress XAF от Галактики, называется Xafari:

https://galaktika.ru/xafari

Но мне ERP-ы совсем неинтересны, если только в качестве их админа со скриптописательством автоматизации админства.

sanyo1234
()
Ответ на: комментарий от byko3y

25-30 тысяч вставок в секунду. Курам на смех. Самый захудалый мускуль выдаст столько же на жестком диске при условии пакетной вставки.

Как-то странно, вроде Тарантулом удавалось заменить пачку MySQL серверов?

https://medium.com/@denisanikin/how-to-save-one-million-dollars-on-databases-...

А что думаешь по поводу относительно малоизвестного Reindexer?

https://github.com/restream/reindexer#sql-compatible-interface

https://habr.com/ru/post/346884/

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

И в то же время не знаешь про DBF в 1Це :) но это ерунда, прошлый век как говорится.

sanyo1234
()
Последнее исправление: sanyo1234 (всего исправлений: 2)
Ответ на: комментарий от byko3y

Ты отвечал по поводу проекта более-менее универсальной СУБД для публичного пользования — вот я тебе и отвечаю про публичный софт, для которого DevExpress не подходит, потому что багованный и нерасширяемый.

Причем тут именно СУБД? DevExpress XAF ObjectSpace provider может цепляться к любым кастом объектным источникам.

Покажи мне, хоть какой-то аналог лучше?

Я не видел более удобного и в тоже время очень функционального набора компонентов для WinForms, чем у DevExpress. Про более поздние типа WPF не скажу, в области Blazor они вообще IMHO были в догоняющих других компонентных вендоров, но это может быть связано как раз с тем, что их Blazor - это один из переключаемых вариантов для показа форм в XAF? А у кого еще есть замена XAF?

sanyo1234
()
Ответ на: комментарий от byko3y

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

Что значит серьезный? По количеству одновременных пользователей или каким еще критериям?

Почему преимущества XAF сходят на нет? Какое железо ты предпочитаешь для деплоя?

Что мешает крутить XAF GUI на Linux x86 (если WinForms, то например внутри WINE на Linux сервере с терминальными сессиями какого-нибудь X2GO) или в случае server side Blazor даже на чистом Linux (без WINE) на ARM hardware?

Тебе нужна возможность запуска GUI на железках, отличных от x86 и ARM? Причем заметь, бизнес логика может быть написана и собрана вообще без привязки к DevExpress например для JVM, и соединена с XAF через ObjectSpace provider + gRPC. Ессно (по крайне мере пока) JVM можно запускать на более широком ассортименте железа и осей, чем dotNET for Linux.

Ты в курсе, что XAF open source? И если MS портирует свой dotNET на новые программно-аппаратные платформы, то автоматически вместе с ним портируется и DevExpress XAF (по крайне мере тот, который Web server side Blazor)? Впрочем для этого вероятно даже ненужно было бы open source-ности DevExpress.

sanyo1234
()
Последнее исправление: sanyo1234 (всего исправлений: 9)
Ответ на: комментарий от sanyo1234

Кстати по теме вашей ветки о ERP-ах, есть как минимум одна на базе DevExpress XAF от Галактики, называется Xafari:
https://galaktika.ru/xafari

Мне нравится их подход «платформа вместо готового решения» — мне не нравится, что они повторили все индустриальные штампы со всеми недостатками онных. Ну типа я на делфи настраиваемые панельки аля «сделай сам ERP» лепил еще когда в школе был. И это был мой первый опыт с ошибками памяти, которые заняли больше половины всех моих усилий над этим проектом. Уже тогда я перестал ставить под сомнение эффективность применения ЯП с безопасной моделью памяти среди даунов — 90% рынка программистов просто не смогут написать ничего на какой-нибудь сихе.

byko3y ★★★★
() автор топика
Ответ на: комментарий от sanyo1234

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

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

И в то же время не знаешь про DBF в 1Це :) но это ерунда, прошлый век как говорится

Локалхостные решения можно налепить на коленке за день-другой. DBF нужен скорее как средство взаимодействия, например, старой системы с новой.

byko3y ★★★★
() автор топика
Ответ на: комментарий от sanyo1234

DevExpress XAF ObjectSpace provider может цепляться к любым кастом объектным источникам

Это красивая история, но в реальности чем более кастомный источник, тем меньше толка от этого самого DevExpress XAF. Я полуготовый провайдер для Firebird из состава DevExpress дорабатывал эдак года два с перерывами — настолько это веселое занятие было.

Покажи мне, хоть какой-то аналог лучше?

Не бывает абстрактного «лучше». Есть конкретная задача, конкретные требования. Если у заказчика требования «сделать на оракле с хранимками» — ты будешь делать на оракле с хранимками.

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

byko3y ★★★★
() автор топика
Ответ на: комментарий от sanyo1234

Что значит серьезный? По количеству одновременных пользователей или каким еще критериям?

Одновременных пользователей. одновременных организаций, зоопарк клиентов, в том числе мобилка и веб, и под всё это требуется фирменный фейс.

Почему преимущества XAF сходят на нет?

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

Какое железо ты предпочитаешь для деплоя?

Не понял вопроса. К тебе придет организация, скажет «вот у нас есть сервер, вот такие у нас клиенты — реализовывайте» — вот и вся история. Как правило, на десктопах и серверах это всегда x86, win/lin, клиенты виндузятники или мобилки — тут особо не повыбираешь «на этом буду деплоить, на этом — не буду».

Что мешает крутить XAF GUI на Linux x86 (если WinForms, то например внутри WINE на Linux сервере с терминальными сессиями какого-нибудь X2GO) или в случае server side Blazor даже на чистом Linux (без WINE) на ARM hardware?

И где ты собрался взять серверный ARM? Еще бы POWER предложил.

Тебе нужна возможность запуска GUI на железках, отличных от x86 и ARM? Причем заметь, бизнес логика может быть написана и собрана вообще без привязки к DevExpress например для JVM, и соединена с XAF через ObjectSpace provider + gRPC. Ессно (по крайне мере пока) JVM можно запускать на более широком ассортименте железа и осей, чем dotNET for Linux

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

Ты в курсе, что XAF open source?

Настолько же опенсорс, насколько опенсорсна винда. То есть, только для своих за большие деньги.

byko3y ★★★★
() автор топика
Ответ на: комментарий от byko3y

Это красивая история, но в реальности чем более кастомный источник, тем меньше толка от этого самого DevExpress XAF. Я полуготовый провайдер для Firebird из состава DevExpress дорабатывал эдак года два с перерывами — настолько это веселое занятие было.

Ты дорабатывал вероятно провайдер DevExpress XPO, ибо Firebird как СУБД навряд ли имеет свой персональный ObjectSpace провайдер.

Я тоже не фанат XPO, хотя бы потому что существует относительно популярный и отточенный для РСУБД почти до совершенства (если правильно готовить) nHibernate с его старшим братом Java Hibernate, где есть даже OGM для noSQL: https://hibernate.org/ogm/

Microsoft Entity Framework - это вообще поделка непонятно для кого, очередной ненужно «питон», который разрекламировала крупная компания.

В DevExpress наиболее интересной частью является их GUI и формошлепно офисная надстройка в виде XAF. ObjectSpace провайдер позволяет биндиться к любым своим кастомным провайдерам под капотом которых может быть и nHibernate, и gRPC+JVM Hibernate и т.п.

sanyo1234
()
Последнее исправление: sanyo1234 (всего исправлений: 1)
Ответ на: комментарий от byko3y

Не бывает абстрактного «лучше». Есть конкретная задача, конкретные требования. Если у заказчика требования «сделать на оракле с хранимками» — ты будешь делать на оракле с хранимками.

И идет такой заказчик лесом вместе со своим Ораклом (который у меня в черных списках неинтересных для меня технологий).

Мне кроме Db2 и PG другие РСУБД вообще неинтересны от словам совсем, только если в качестве поддержки какого-то готового проекта типа WordPress, ну придется мириться с недоMySQL (в качестве его админа для написать кастом скриптик для управления готовыми Ansible WP ролями или потом чем-то готовым в Кубере, что подешаешь ...)

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

Все же явно ты троллируешь, тебе наверно DevExpress доплачивает? :) XAF по сути - это единственная известная мне система, которая с одной стороны позволяет генерить формы из модели почти на автомате, а с другой расширять объектную модель на уровне полного ООП (со всеми наворотами DotNet языков типа шарпа), используя все богатство их отдельных компонентов из комплекта WinForms, WebForms и теперь еще и Blazor:

https://docs.devexpress.com/eXpressAppFramework/113610/ui-construction/using-...

Вообще очень печально, что про XAF почти забыли в РФ, здесь видимо не место для быстрой разработки формочек, а место для ИМБУРДешников, особенно в госухе, ведь без XAF их можно формошлепить на одном и том же одномротном месте во много раз дольше, а значит теоретически питательнее :)))

sanyo1234
()
Последнее исправление: sanyo1234 (всего исправлений: 3)
Ответ на: комментарий от byko3y

Одновременных пользователей.

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

Собственно ради этого мне и нужна данная ветка про ERP, но предметная область ERP интересна почти настолько же, насколько и Oracle :) Почти, потому что Oracle неинтересен даже в качестве DBA :)

одновременных организаций, зоопарк клиентов, в том числе мобилка и веб, и под всё это требуется фирменный фейс.

Ну так намного проще использовать унифицированную хотябы в плане кодовой базы платформу, да еще с готовыми возможностями переключать themes, лепить свои кастом контролы и т.п., чем изобретать свои велосипеды, в которых вероятно 90% GUIшного кода -это то, что мог бы исполнить XAF из коробки. Причем качество и охват решаемой задачи унификации формошлепства этого кастом кода вероятно в большинстве случаев будет ниже XAF и в лучшем случае охватит только малый процент возможностей XAF и это даже для средних и некоторых крупных компаний с огромными бюджетами, а про мелочь так вообще только посмеяться.

Вообще в РФ судя во форумам XAF-еров раньше гнали ссаными тряпками, потому что они лишали работы тех, кто с умным видом делает ненужно на протяжении очень долгих лет. А сейчас XAF-а в РФ почти не осталось, зато его много в Германии.

Но внимание, зато в РФ много SAP R3, LOL :)))))

Меняем г*но бусы на ништяки из Тулы, ничего не напоминает? Не иначе, С. Поток N3 :)

sanyo1234
()
Последнее исправление: sanyo1234 (всего исправлений: 6)
Ответ на: комментарий от byko3y

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

Что конкретно-то не расширяется? Может просто недостаточно знаний для расширения?

Но даже в пределах этих рычагов могут всплывать баги.

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

sanyo1234
()
Ответ на: комментарий от byko3y

Не понял вопроса. К тебе придет организация, скажет «вот у нас есть сервер, вот такие у нас клиенты — реализовывайте» — вот и вся история.

Ты случаем не из бодижопа вещаешь во время передышек между весланием?

Может ли в продуктовую компанию прийти кто-то и начать втирать им дичь?

Как правило, на десктопах и серверах это всегда x86, win/lin, клиенты виндузятники или мобилки — тут особо не повыбираешь «на этом буду деплоить, на этом — не буду».

Ну так даже для твоих рабских оков x86 в XAF поддерживается таки да, и даже Linux, сюрпрайз ?!? :)))

sanyo1234
()
Ответ на: комментарий от byko3y

И где ты собрался взять серверный ARM? Еще бы POWER предложил.

Я поэтому и спрашивал, что ты подразумевал под парком железа?

применяется только на ограниченном парке железа

Наверно огромные серверные с ненужным металлоломом, которые хостят огромные слабоинтегрированные зоопарки систем - выкидышей бодишопных тендеров :)

sanyo1234
()
Последнее исправление: sanyo1234 (всего исправлений: 1)
Ответ на: комментарий от byko3y

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

Да что ви говорите, вообще-то у DotNet огромное количество преимуществ по сравнению с Java, если не рассматривать маргинальные случаи типа кодинга для Java смарткарт, о которых btw. некоторые безопасники не самого лучшего мнения.

Особенно хороши языки программирования типа C#, F# и VB.NET.

Java может быть интересен только для деплоя на относительно редкие архитектуры, куда еще не добрался DotNet, типа OpenBSD на SPARC-ах например, но вероятно это вопрос времени и рыночной коньюктуры. Например, на FreeBSD заинтересованные лица уже вовсю относительно успешно портируют .NET Core пока еще приватно.

sanyo1234
()
Последнее исправление: sanyo1234 (всего исправлений: 3)
Ответ на: комментарий от byko3y

Настолько же опенсорс, насколько опенсорсна винда.
То есть, только для своих

Ну зачем так толсто троллить, зайди на сайт:

https://www.devexpress.com/buy/net/

Раскрой полную таблицу сравнения и посмотри в какие редакции включены сорцы.

за большие деньги.

Дооо, боюсь, что на кастом inhouse породия тратят в десятки и сотни раз больше (по крайне мере человекочасов по сравнению с экономией часов при использовании готового) и при этом в большинстве случаев даже никогда не получат сравнимого качества и функционала.

sanyo1234
()
Последнее исправление: sanyo1234 (всего исправлений: 3)
Ответ на: комментарий от sanyo1234

Вообще в РФ судя во форумам XAF-еров раньше гнали ссаными тряпками, потому что они лишали работы тех, кто с умным видом делает ненужно на протяжении очень долгих лет. А сейчас XAF-а в РФ почти не осталось, зато его много в Германии

Ты так пишешь, будто в России сидят одни кретины, которых волнует лишь одна проблема — как бы быстрее потратить бюджет. Посмотри на стоимость лицензии XAF — 2000$/год. За такие деньги в России тебе чуть ли не с нуля на коленке напишут твои пять формочек — потому и покупают XAF только в зажравшейся Гермашке, да и то не везде. А на что-то более сложное и кастомное брать XAF уже нет смысла — с нуля напишешь быстрее, чем с «готовой» либой.

Но внимание, зато в РФ много SAP R3, LOL

1С намного больше.

byko3y ★★★★
() автор топика
Ответ на: комментарий от sanyo1234

Что конкретно-то не расширяется? Может просто недостаточно знаний для расширения?

Исходил сорцы вдоль и поперек. По крайней мере тех компонентов, с которыми работал. Я уже написал — это лапша и ООП головного мозга в терминальной стадии, которые выжили только благодаря огромному числу ресурсов, потраченных на разработку и тестирование. Толкнешь его не с той стороны — всё посыпется. Еще раз: я нашел порядка десяти багов за годы работы с DevExpress-ом. Это неизбежный результат чрезмерной сложности, и он был бы не сильно лучше даже если бы разрабы грамотно подошли к организации архитектуры, а не тупо «по книжкам», как они это сделали.

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

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

byko3y ★★★★
() автор топика
Ответ на: комментарий от sanyo1234

Ты случаем не из бодижопа вещаешь во время передышек между весланием?
Может ли в продуктовую компанию прийти кто-то и начать втирать им дичь?

У тебя есть очень простой выбор: выполнять заказ клиента или терять клиента. Если у клиента на всех клиентах и серверах стоит винда, а ты им говоришь «всё херня, давайте ставить линь» — ты теряешь клиента. Вот и вся история.

byko3y ★★★★
() автор топика
Ответ на: комментарий от sanyo1234

Ну зачем так толсто троллить, зайди на сайт:
https://www.devexpress.com/buy/net/

А теперь разверни строчку «Source code» и посмотри, что сорцы к XAF ты получишь только за самую жирную подписку.

Дооо, боюсь, что на кастом inhouse породия тратят в десятки и сотни раз больше (по крайне мере человекочасов по сравнению с экономией часов при использовании готового) и при этом в большинстве случаев даже никогда не получат сравнимого качества и функционала

Несколько месяцев работы средненького провинциального кодера — это стоимость лицензии XAF.

byko3y ★★★★
() автор топика
Последнее исправление: byko3y (всего исправлений: 1)
Ответ на: комментарий от byko3y

Ты так пишешь, будто в России сидят одни кретины, которых волнует лишь одна проблема — как бы быстрее потратить бюджет.

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

Посмотри на стоимость лицензии XAF — 2000$/год.

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

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

За такие деньги в России тебе чуть ли не с нуля на коленке напишут твои пять формочек

Которыми можно только *опу подтереть, если речь именно о usability и надежности и других различных критериях годности именно формошлепства.

Бизнелогику придется в любом случае разрабатывать самостоятельно, но в модели DevExpress есть масса удобств типа валидаторов значений и т.п.

— потому и покупают XAF только в зажравшейся Гермашке, да и то не везде.

А еще они на запорах не ездят, и РФ кстати последнее время тоже почему-то запоры стали непопулярны на дорогах, но в формошлепстве с этим хуже, вероятно если в РФ начать использовать XAF, то некоторым представителям, упомянутым в первом параграфе данного сообщения, придется присесть из своих мерсов как минимум в запоры.

А на что-то более сложное и кастомное брать XAF уже нет смысла — с нуля напишешь быстрее, чем с «готовой» либой.

Пример XAF на сайте DevExpress, там кажется шла речь за сколько-то минут создать простое приложение с look and feel MS Office и в тоже время с XAF моделью и вот этим всем. Но конечно есть еще и порог вхождения, чтобы понимать, как делать кастом контролы для чего-то посложнее.

sanyo1234
()
Последнее исправление: sanyo1234 (всего исправлений: 6)
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.