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

[ibc]

Сейчас в небольших корпарациях объем базы 2-3 Гига, озу серверов 32-64 Мега, так что уже можно использовать ЕРП на объектах Джавы, но увы - никто их писать не собирается, очевидно что то в вашей теории их не устраивает, а вот если бы все устраивало, такие учетные системы имели бы коммерческое применение!

[macklakov]

Цитата:

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

Сейчас в небольших корпарациях объем базы 2-3 Гига, озу серверов 32-64 Мега, так что уже можно использовать ЕРП на объектах Джавы, но увы - никто их писать не собирается, очевидно что то в вашей теории их не устраивает, а вот если бы все устраивало, такие учетные системы имели бы коммерческое применение!

Пишут, но мало, т.к.:
1. Клиенты на Java тормозят, а сервера приложений недостаточно проработаны. Из-за этого негативное отношение к технологии
2. Не так много людей, которые понимают ООП, а тем более серверные приложения
3. Не вкладываются деньги в продвижение
4. Почти все присутствующие на рынке ERP создавались до появления J2EE

Не ООП, но исходя из тех же предпосылок появился прием, когда 1С разгоняют, помещая файлы данных в ОЗУ
P.S. Подумал о 1С и сформулировалась еще одна причина:
5. Сама технология молода. Ведь даже через 20 лет после появления промышленных РБД, продолжали делать системы основанные на файловом хранении и мотивировали тем, что так проще.

[Pavel]

Цитата:

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

Ведь рабочие будут в памяти, в виде объектов. В этом вся фишка, что данные не нужно получать и сохранять, они все время под рукой.
...
Часть, конечно, останется в табличной форме, т.к. это наиболее естественно. К примеру, таблица закзов. Но вот строки заказов, это уже атрибуты самих заказов. А колличество запросов и их сложность резко снизится, т.к. к запросы по связанным таблицам, это скорее исключение.
…
Это при условии, что будет принята идеология J2EE, а не набор ad hoc-ов...

Зачем все собирать в кучу, методы хранения информации, методы представления объектов в приложении, способы их технической реализации, пользовательские интерфейсы… а затем все в J2EE и против РБД?

Не понятна целесообразность такого подхода. Какая преследуется цель? В чем ее практическая ценность?

«Память будет больше – все в память – быстрее обработка», а что быстродействие самый актуальный вопрос? Тогда как быть с сохранностью информации (в том числе долгосрочной), а надежностью системы, энергонезависимостью и т.п.

P.S. Наблюдение: архитектура сооружений – отдельная наука, материаловедение – отдельная наука. Находим новый материал, ищем ему применение (т.е. пользу), применяем, изучаем последствия, распространяем…
В перспективе => непредсказуемо: он может со временем вытеснить известные ранее материалы, может занять свою отдельную нишу или исчезнуть, сам замененный чем-либо.

[macklakov]

Цитата:

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

Зачем все собирать в кучу, методы хранения информации, методы представления объектов в приложении, способы их технической реализации, пользовательские интерфейсы… а затем все в J2EE и против РБД?

Начнем с того, что серверные компоненты не имеют отношения к пользовательским интерфейсам. А хранение информации они как раз позволяют отвязать от логики. Объекты можно сериализовать как в РБД, так и в ОБД и в XML и в бинарный файл...

Цитата:

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

Не понятна целесообразность такого подхода. Какая преследуется цель? В чем ее практическая ценность?

Те же, что и при переходе с 2-х уровневой на 3-х уровневую аксапту. Кроме того, это позволит отвязать логику и представление данных от способа их хранения

Цитата:

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

«Память будет больше – все в память – быстрее обработка», а что быстродействие самый актуальный вопрос?

Один из ограничивающих. Т.к. из-за быстродействия часто отказываются от многих возможностей.

Цитата:

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

Тогда как быть с сохранностью информации (в том числе долгосрочной)

есть такой термин, "сериализация"

Цитата:

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

а надежностью системы, энергонезависимостью и т.п.

расскажите, что происходит, если обесточить RAID?

Цитата:

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

P.S. Наблюдение: архитектура сооружений – отдельная наука, материаловедение – отдельная наука. Находим новый материал, ищем ему применение (т.е. пользу), применяем, изучаем последствия, распространяем…

Архитектурное решение очень сильно зависит от выбранных материалов Из дерева небоскреб не построишь, а из стали изба тоже не очень хорошая получится