На сколько оправдана концепция ОПП в средствах разработки ERP-систем?

[Yoil]

Цитата:

Сообщение от otkudao

По поводу Навижна, как самописки. Хочу уточнить, что имел в виду:
знакомился с базовой конфигурацией Нав года 3 назад, Для себя сделал вывод: система удобна для программистов, а не для пользователей. Подходы и стандартные концепции-примитивы позволяют быстро накидать тучу-хучу объектов в систему, через которые пользователь будет "ногу задирать", проклиная треклятых програмистов. И наработок функционала , продуманных и реализованных цепочек-бизнес-процессов с гулькин клюв.

Вывод: автор системы как бы говорит: "вот вам шаблоны примитивные, конструируйте ваши бизнес-процессы с помощью моих трех кубиков, пользователель схавает".

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


[Posted by 192.168.0.33. This is added while posting a message to avoid misuse of WebWarper: see [url=http://webwarper.net/han[/url] Example of using WebWarper: На сколько оправдана концепция ОПП в средствах разработки ERP-систем?]На сколько оправдана концепция ОПП в средствах разработки ERP-систем? ]

Долго думал, стоит ли отвечать, таки решил ответить.
otkudao, Вы работали с Navision или просто видели его?
Если просто видели, то откуда у вас столько знаний о стандартных концепциях-примитивах, о принципах построения бизнес-процессов в Navision, чтобы писать такую чушь?
А если Вы в ней работали, то не могли бы как-то аргументировать свои слова?
"Я Пастернака не читал, но осуждаю"...

[ibc]

Цитата:

Вы что, готовы реализовать свою ERP без принципов ООП? На спагетти-коде может быть наляпаете?

Был такой язык COBOL...

[Yoil]

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

[SVG]

Yoil

цитирую:
otkudao - Таково было мое поверхностное мнение

Yoil, ну и чего ты пристал к otkudao? Каждое мнение имеет право на существование, в том числе и поверхностное. Я вот тоже сидел в ауди А-6 - не понравилось.... как-то все непривычно, не так как-то все.. такое впечатление, что дали 6 кнопок в сиденьи, и все, и делай с регулировками что хочешь. Для автомехаников может и удобно, а для пользователей гораздо проще нажать кнопку "Иван Пупкин" и сразу что все обана и круто стало. Желательно чтоб кнопка была большой и красной. И посередине

[Pavel]

Цитата:

Сообщение от SVG

Yoil, ну и чего ты пристал к otkudao? Каждое мнение имеет право на существование, в том числе и поверхностное.

Поддерживаю.

[Yoil]

Цитата:

Сообщение от Yoil

Нет, otkudao, я в таком случае пас

Я уже отстал

[Тимур]

Вопрос к апологетам ООП:
скажите, плиз, а вы знаете хотя бы одну ERP-систему, которая была разработана с использованием ООП?

[Yoil]

Это скорее к апологетам ерп...
Немного народу знает больше 2-х систем... А большинство одну
Хотя, например, друг у меня занимается тем, что пишет на жабе ерп "под ключ" (в смысле не один, контора его этим занимается). Они все ооп

[Тимур]

Ну да. Понятно. Русских кулибиных не истребить. Даже если денег не платить.
Хочется услышать об уже давно работающих ERP-системах.

[belugin]

>>>скажите, плиз, а вы знаете хотя бы одну ERP-систему, которая была разработана с использованием ООП?

По-моему, при разработке Аксапты оно немного использовалась. В принципе, таблицы в Axapte есть объекты в стиле старых версий VB (кажется, в книжке Буча табие языки назывались объектными в отличие от объектно-ориентированных)

А вообще интересно будет, когда либо появятся объектные СУБД либо ОО-языки станут более декларативными и будут лучше отображаться на RDBMS (Например, вот что пытается сделать MS).



Сейчас все большую популярность приобретают средства такого отображения. Например сейчас много шуму наделал Ruby on Rails, который включает в себя средство отображения объектов на СУБД и в вебинтерфейс.

ERP (по крайней мере известные мне) конечно штуки заскорузлые в плане технологии, но и до них это когда-нибудь долезет.

[Тимур]

А зачем искусство ради искусства? Кто будет платить за "банкет"?

[belugin]

зачем ООП вообще? зачем отображение на РБД?

[macklakov]

Цитата:

Сообщение от belugin

зачем ООП вообще? зачем отображение на РБД?

Затем, что главное назначение РБД, быстрый доступ к данным на МАГНИТНОМ носителе. Но с 64-х разрядной архитектурой, можно будет всю базу держать в оперативной памяти, а сохранение на диск будет аналогом бэкапа. Соответственно, реляционное представление данных должно потерять свою актуальность, данные и способы обработки станут более приближенными к предметной деятельности. А ООП, хороший способ их систематизировать.
Хотя, конечно, эмуляции РБД (вроде аксаптовских tmpTable и dataSource), продолжат существование, т.к. слишком много народу привыкло мыслить этими категориями.

[skof]

Мое мнение таково - ООП это очень интересный способ структурирования, оптимизации и повторного использования кода...
Но... честно говоря "дружественные" функции реализованные в С++ у меня например вызывают некоторую настороженность...
В Аксапте ООП применяется по сути своей просто для структурирования кода ответсвенного за бизнес процессы и большое спасибо Damgaard-у что он не полез глубже... ибо а зачем?
Конечно в том случае когда вся система проектируется заранее можно с помощью ООП такого наворотить... но вот когда ее еще раз двадцать переделают тогда мне кажется чем проще-тем лучше...

[simply2double]

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

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

Поэтому хватит базарить, идите программируйте

[Pavel]

Цитата:

Сообщение от macklakov

Затем, что главное назначение РБД, быстрый доступ к данным на МАГНИТНОМ носителе. Но с 64-х разрядной архитектурой, можно будет всю базу держать в оперативной памяти, а сохранение на диск будет аналогом бэкапа. Соответственно, реляционное представление данных должно потерять свою актуальность, данные и способы обработки станут более приближенными к предметной деятельности. А ООП, хороший способ их систематизировать.

Оригинально. Табличную форму хранения информации человек использовал задолго до появления терминов СУБД, ООП... вряд ли она потеряет свою актуальность при изменении разрядности процессоров (64-х, 128-ми и т.д.). Нормированные таблички - это математика, а разрядность вычислительной архитектуры - степень возможности человека материализовать математику в своих технологиях.

[macklakov]

Цитата:

Сообщение от Pavel

Оригинально. Табличную форму хранения информации человек использовал задолго до появления терминов СУБД, ООП...

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

Цитата:

Сообщение от Pavel

Нормированные таблички - это математика

Если не ошибаюсь, этой математике порядка 30-40 лет и создавалась она под конкретную задачу.

Цитата:

Сообщение от Pavel

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

Я другой аспект имел в виду. Повышенная разрядность это, в первую очередь, повышенный объем оперативной памяти, что избавляет от необходимости хранить значительную часть данных на магнитных носителях.
P.S. Хотя, наверное, для Вас мои слова звучат как ересь, особенно, если учесть, что SAP появился благодаря появлению РБД, а появление РБД было вызвано в первую очередь учетными системами...
P.S.S. Подтверждение недостаточности реляционной архитектуры, можно увидеть в любой промышленной СУБД. Сложные языки хранимых процедур, тригера, вьюхи, это эмуляция объектного подхода. Прямое изменение данных таблиц считается дурным тоном, т.к. часто эти изменения должны отразиться еще в несколько таблиц, а до конца структуру данных не знает никто.

[Pavel]

Цитата:

Сообщение от macklakov

Если не ошибаюсь, этой математике порядка 30-40 лет и создавалась она под конкретную задачу.

"ЛАТИНСКИЙ КВАДРАТ, квадратная таблица n2 чисел, каждая строка и каждый столбец которой содержат числа 1, 2,..., n. Напр., для n = 3
2 3 1
3 1 2
1 2 3
Латинские квадраты применяются в комбинаторике.

ЛЕГИОН, в древнерусском счете 100 тыс.

ЛЕЖАНДРА МНОГОЧЛЕНЫ, специальная система многочленов, ортогональных с весом 1 на отрезке [-1;1]. Рассматривались А. Лежандром и П. Лапласом (в 1782-85)."
http://mathforall.narod.ru/formuls/1.10.htm

Для себя поинтересовался историей данного вопроса... однако, не менее двух столетий.

Цитата:

Сообщение от macklakov

Хотя, наверное, для Вас мои слова звучат как ересь, особенно, если учесть, что SAP появился благодаря появлению РБД, а появление РБД было вызвано в первую очередь учетными системами...

Кроме SAP у меня еще девять лет опыта работы с продуктами MBS.
Поддерживаю вашу мысль, прикладные языки XAL (Конкорд от Damgaard), C/AL (Navision) из семейства 4GL являются интерфейсами к РБД или тем, что называют СУБД. Аксапта со своими средствами разработок не избавилась от триггеров, форм, запросов и прочих элементов СУБД. Что не позволяет противопоставлять ООП и РБД. Не согласны?

Цитата:

Сообщение от macklakov

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

Полагаете аксапта с ООП избавилась от всего выше перечисленного?

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

[belugin]

вы пытались работать с ООСУБД?

[macklakov]

Цитата:

Сообщение от Pavel

Аксапта со своими средствами разработок не избавилась от триггеров, форм, запросов и прочих элементов СУБД. Что не позволяет противопоставлять ООП и РБД. Не согласны?
Полагаете аксапта с ООП избавилась от всего выше перечисленного?

Для начала повторюсь, что аксапта реализует лишь некоторые аспекты ООП. А от хранения данных в СУБД невозможно отказаться, пока память медленная и ограничивается 4ГГб. Хотя, AOS пытается это делать.

Цитата:

Сообщение от Pavel

Для себя поинтересовался историей данного вопроса... однако, не менее двух столетий.

Простите, мы об одном и том же говорим? Я говорю о реляционной алгебре.

Цитата:

Сообщение от http://www.3ka.mipt.ru/vlib/citforum/database/dblearn/dblearn02.shtml

Основы реляционной модели данных были впервые изложены в статье Е.Кодда в 1970 г.