Новый Большой проект на FPC - стоит ли рискнуть?

[vada]

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

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

Стеклянного шара у меня нет, но пользуясь своим опытом могу предположить:
1) Таблиц базы данных от 60 до 100
2) Сложная бизнес-логика
3) Множество ролей пользователей
4) групповой разделяемый доступ к информации
5) множество входных и выходных бумажных документов.

Давайте попробуем прикинуть во что выльется разработка на лазарусе (паскаль) и, допустим, нетбинс (джава).
1) Есть ли в лазарусе UML? Какой инструмент поможет вам в лазарусе описать структуру потоков данных и взаимодействие событий, взаимодействие ролей, пользователей? Ничего нет. На бумажке рисовать будете? И сколько таких бумажек наплодите? А если вспомнить что такая структура живет и изменяется во время всего жизненного цикла системы, то получается что это никак не решить. А вот для JAVA подобных систем если сказать полно, ничего не сказать.

2) Разработка структуры базы данных. Опять упираемся в UML. Ручками SQL формирования базы рисуем, или в PAdmin, или еще что? Подобные системы вовсе не для этого. В UML рисуются такие вещи. SQL генерится одним нажатем пипки.
Для лазаруса этого нет, для джавы навалом.

3) Проблема хранения persistent модели данных. В лазарусе некоторые зачатки этой системы есть, но они весьма глючные и ограниченные по своим возможностям. Сохранность данных при падении программы они нифига не обеспечивают. Если своего ПРАВИЛЬНОГО не написать, то придется смириться что система будет неустойчивая и ненадежная. В JAVA эти вопросы давно решены. Есть J2EE, масса фреймворков. Как говорится - с плеча, с бедра, с колена...

4) Бизнес-логика. К сожалению, система GUI типа Delphi, Lazarus не позволяет отделить суп от мух. Все жестко взаимосвязана с обработкой событий от мышководов и событий масштаба логики прохождения документов. Отодрать их друг от друга невозможно. Это еще один трабл который надо будет как-то решать в лазарусе. В J2EE это решено давным давно. Реализовано куча классов интерфейсов... Бери программист пользуйся и будь уверен - вылизано все давно и качествено.

5) Разделение доступа к данным. Ивините меня может я отстал от жизни, но ни в дельфи ни в лазарусе в компонентах работы с базой данных и намека раньше не было на это. Все заточено было на единоличное пользование всеми ресурсвми базы. Ну накрайняк можно было получить информацию что таблица кем-то монопольно захвачена. Это напоминает ковыряние в часовом механизме шуруповертом. Для группового доступа к данным вообще не подходит. В J2EE это решено на уровне Sessin Bean. Разделение по ролям пользователей решено плодь до доступа к полю, не говоря уже о таблице.

6) Теперь о выходных документах. Инструментов для формирования различных документов в лазарусе просто нет. LazReport просто несерьезно. Ну да, можно сделать отчет по выборке из БД, но в подобных системах это 10% от всего требуемого. Потом встает вопрос передачи выходных документов в другие системы обработки информации. В тот же офис. Тоже непомерная дыра. То что есть, даже не смешно. В JAVA опять же с плеча с бедра с колена.

Это я еще не говорю о мощности IDE для JAVA. Эти системы специально заточены для решения подобных задач и почти половина кода генерируется просто нажатием той или иной педали. Потом система JUnit. Зачатки ее в лазарусе есть, но все надо делать лапами. В NetBeans Eclipcse IDE генерятся нажатием педали.

Я вовсе не хочу сказать что на лазарусе нелязя реализовать заданную в первом посте задачу. Можно. Только трудоемкость будет, я вас уверяю, на порядок больше чем та же реализация на JAVA. И глючная система будет!!!!! Почти все нужно писать с нуля и отлаживать крайне сложно. Про сопровождение даже не говорю. Сколько раз было что приходилось вносить изменения и в структуру БД когда система уже три года работает, и самое неприятное в бизнес-логику. Директор экономя средства упраздняет отдел, и их функции распыляет по другим подразделениям. Вот жопа так жопа. Бери мочало начинай сначала. В JAVA если все правильно сделано в соответствии с EJB, проблема решаема малой кровью. В лазарусе переписывать пол проекта придется.

[ronin]

Есть ли в лазарусе UML? Какой инструмент поможет вам в лазарусе описать структуру потоков данных и взаимодействие событий, взаимодействие ролей, пользователей? Ничего нет. На бумажке рисовать будете?

рисую в других программах и ничего

Разработка структуры базы данных. Опять упираемся в UML. Ручками SQL формирования базы рисуем, или в PAdmin, или еще что?

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

Бизнес-логика. К сожалению, система GUI типа Delphi, Lazarus не позволяет отделить суп от мух. Все жестко взаимосвязана с обработкой событий от мышководов и событий масштаба логики прохождения документов. Отодрать их друг от друга невозможно. Это еще один трабл который надо будет как-то решать в лазарусе. В J2EE это решено давным давно. Реализовано куча классов интерфейсов...

тут вообще ничего не понял

Разделение доступа к данным. Ивините меня может я отстал от жизни, но ни в дельфи ни в лазарусе в компонентах работы с базой данных и намека раньше не было на это. Все заточено было на единоличное пользование всеми ресурсвми базы. Ну накрайняк можно было получить информацию что таблица кем-то монопольно захвачена. Это напоминает ковыряние в часовом механизме шуруповертом.

вообще то это вы как раз не отделяете мух от котлет, вся логика и разделение прав доступа/управление транзакциями и контроль непротиворечивости данных всегда ложилась на сервер БД, причём тут компоненты в IDE? у меня компоненты используются для отображения/редактирования данных + хранимые процедуры, остальное работа сервера БД

Теперь о выходных документах. Инструментов для формирования различных документов в лазарусе просто нет. LazReport просто несерьезно.

несерьёзно почему? вы пробовали? или это просто ваше мнение не основанное на практическом опыте?

и почти половина кода генерируется просто нажатием той или иной педали. .

опыт подсказывает что как раз после нажатия этих педалей приходится ещё перелопачивать весь это хлам ИМХО

Я вовсе не хочу сказать что на лазарусе нелязя реализовать заданную в первом посте задачу. Можно. Только трудоемкость будет, я вас уверяю, на порядок больше чем та же реализация на JAVA. И глючная система будет!!!!!

вывод на основе ваших умозаключений? почему вы так решили?

Почти все нужно писать с нуля и отлаживать крайне сложно

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

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

каким образом это связано с выбором языка и IDE? по моему это как раз зависит от способа реализации и прямоты рук разработчика, но никак не от выбранных инструментов

[WAYFARER]

вся логика и разделение прав доступа/управление транзакциями и контроль непротиворечивости данных всегда ложилась на сервер БД, причём тут компоненты в IDE? у меня компоненты используются для отображения/редактирования данных + хранимые процедуры, остальное работа сервера БД

+100500!

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

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

[Padre_Mortius]

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

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

[vada]

рисую в других программах и ничего

IDE для JAVA все в одном флаконе. Изменил UML изменились класся в проекте.

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

См выше.

тут вообще ничего не понял

Не удивляет

вообще то это вы как раз не отделяете мух от котлет, вся логика и разделение прав доступа/управление транзакциями и контроль непротиворечивости данных всегда ложилась на сервер БД, причём тут компоненты в IDE? у меня компоненты используются для отображения/редактирования данных + хранимые процедуры, остальное работа сервера БД

Это вы не в курсе. Перекладывать бизнес-логику на SQL сервер это тупиковый путь в никуда. Давно доказано. При смене, иногда, даже версии SQL перестает работать. Про перенос на другой SQL даже не говорю. Проекты такого уровня, как правила, нуждаются в масштабировании. SQL сервер частенько становится слаб для задачи. Опять же еще один язык программирования в проекте.

несерьёзно почему? вы пробовали? или это просто ваше мнение не основанное на практическом опыте?

Не поверите! Пробовал. Когда вам нужно по одному макету сделать документ PDF, DOC, ODF. LazReport очень вам поможет

опыт подсказывает что как раз после нажатия этих педалей приходится ещё перелопачивать весь это хлам ИМХО

Жизнь не удалась? Это где же вам так генерят?

вывод на основе ваших умозаключений? почему вы так решили?

Один и тот же проект был написан на FoxPro, потом на Delphi, потом на J2EE. В проекте на J2EE было фич раз в десять больше и работало на удивление надежнее.

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

Заблуждение. Управленческие проекты и документооборот одинаковые как блины. Содержат определенный набор блоков и работают одинаково.

каким образом это связано с выбором языка и IDE? по моему это как раз зависит от способа реализации и прямоты рук разработчика, но никак не от выбранных инструментов

Еще одно заблуждение. Жопорукость конечно ни кому не помогает, но IDE в котором изменение в UML модели ведет к изменению кода проекта, очень помогает и в разработке и в сопровождении. Про групповую разработку и не говорю. А лазарус он для индивидуалистов. Вы, видимо, не работали с большими проектами и в большой группе.

Например, есть такой комерческий продукт Together называется. Он не зря так называется. Сейчас им владеет Борланд, если он еще живой. Куплен борландом с целью прибить конкурента JBuilder. Так в этой IDE весь цикл от начала до конца в одном флаконе. Честно говоря, ни NetBeans ни Eclipse ни IDE до него не дотягивают. Lazarus вообще не в теме.

Добавлено спустя 6 минут 26 секунд:

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

Это дешевый отмаз. ВСЕ продумать заранее не возможно.

[ronin]

Это вы не в курсе. Перекладывать бизнес-логику на SQL сервер это тупиковый путь в никуда.

теперь читайте внимательно

Разделение доступа к данным. Ивините меня может я отстал от жизни, но ни в дельфи ни в лазарусе в компонентах работы с базой данных и намека раньше не было на это. Все заточено было на единоличное пользование всеми ресурсвми базы. Ну накрайняк можно было получить информацию что таблица кем-то монопольно захвачена. Это напоминает ковыряние в часовом механизме шуруповертом.

вообще то это вы как раз не отделяете мух от котлет, вся логика и разделение прав доступа/управление транзакциями и контроль непротиворечивости данных всегда ложилась на сервер БД, причём тут компоненты в IDE? у меня компоненты используются для отображения/редактирования данных + хранимые процедуры, остальное работа сервера БД

вы точно понимаете о чём речь?

При смене, иногда, даже версии SQL перестает работать.

версии чего?

Про перенос на другой SQL даже не говорю

здесь вообще то тема не о переносе проекта или вы считаете что при разработке на java при переносе на другой Sql сервер педаль сама заменит весь код sql запросов с учётом синтаксиса данного сервера?

Один и тот же проект был написан на FoxPro, потом на Delphi, потом на J2EE. В проекте на J2EE было фич раз в десять больше и работало на удивление надежнее

ну и где же тут доказательство несостоятельности/ущербности языка/IDE? чувствуете на что намекаю?
у меня пять крупных проектов на Delphi и не поверите всё работает очень даже стабильно уже несколько лет

но IDE в котором изменение в UML модели ведет к изменению кода проекта, очень помогает и в разработке и в сопровождении

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

Вы, видимо, не работали с большими проектами и в большой группе.

не поверите, работаю

[vada]

вы точно понимаете о чём речь?

Понимаю

версии чего?

SQL сервера

здесь вообще то тема не о переносе проекта

Разработка проекта подобного масштаба предполагает возможность переноса на другой SQL сервер

или вы считаете что при разработке на java при переносе на другой Sql сервер педаль сама заменит весь код sql запросов с учётом синтаксиса данного сервера?

А чего вы улыбаетес? Именно так. Например в фреймворке Hibernate я просто указываю в контексте что у меня теперь SQL сервер не MySQL а PostgreSQL или DB2. Все! Вообще не имею деля с кодом SQL.

ну и где же тут доказательство несостоятельности/ущербности языка/IDE?

Нигде. Я просто пытаюсь довести до вас что разработка на JAVA подобных систем эффективнее.
Вы что-то делати используя J2EE/EJB/Servlet/JSP/JSF... Можите сравнить с разработкой на лазарусе?
Скорее всего нет. Ну так о чем спор?

[ronin]

Например в фреймворке Hibernate я просто указываю в контексте что у меня теперь SQL сервер не MySQL а PostgreSQL или DB2. Все! Вообще не имею деля с кодом SQL

даже с учётом того что какие то функции/параметры могут быть удалены а какие то добавлены в новой версии сервера? если это так, снимаю шляпу

Разработка проекта подобного масштаба предполагает возможность переноса на другой SQL сервер

Это дешевый отмаз. ВСЕ продумать заранее не возможно.

ваши слова

Вы что-то делати используя J2EE/EJB/Servlet/JSP/JSF... Можите сравнить с разработкой на лазарусе?
Скорее всего нет. Ну так о чем спор?

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

[amateur]

Привет.
1. Лазарь - глючное создание. Много проблем и много недоработок. (может кажется, но: в первых версиях лазаря проблем менше было).
2. Лаз репорт - ломается часто... Экспрорт в пдф - нонсенс (даже тестовый пример вылетом и зависом страдает). Да и предварительный просмотр у него с юмором:) ...
Удобство в лазаре есть, но глюков намного больше. За фпс точно не скажу, но и там без проблем не обойтись...

Вопрос: стоит ли рисковать, делая такого монстра на экспериментальной технологии, или лучше обратится к проверенным Java и C++?

- тут краше второй вариант. Хотя, Вам решать...

[vada]

даже с учётом того что какие то функции/параметры могут быть удалены а какие то добавлены в новой версии сервера? если это так, снимаю шляпу

Все не так. От SQL сервера требуется только INSERT, UPDATE, SELECT и в очень редких уникальных случаях DELETE. Согласитесь, накосячить тут сложно. Тем более что JDBC драйвер позволяет от СУБД получить информацию о типах данных и как они соотносятся с типами JAVA. Да и еще кучу инфы получить о сервере.
Т.е. мощь SQL сервера вообще не используется, но такой подход позволяет не напрягаясь махнуть SQL сервер. Данные могут быть хоть в текстовом файле, хоть в DBF. Есть JDBC драйвер? Вперед! EJB и разработана для распределенных систем где данные хнанятся хоть в ведрах с краской. У меня, например, данные приходили по мылу, парсились и импортировались в базу.

На язык и IDE и в мыслях не было нападать. На паскале работаю с времен TURBO 3.0. Считаю паскаль самым читаемым языком. И сейчас делаю проект не на JAVA а на лазарусе+паскаль. Но было время, работал на джаве. И убежден что озвученный в топике проект эффективнее делать на JAVA.

[ronin]

Т.е. мощь SQL сервера вообще не используется, но такой подход позволяет не напрягаясь махнуть SQL сервер.

о_О интересный подход, но как насчёт обратной стороны медали - переносе на другой язык/среду? думаю тут те же самые грабли (если уж говорить про масштабируемость и гибкость проекта)

[vada]

но как насчёт обратной стороны медали - переносе на другой язык/среду? думаю тут те же самые грабли

Немного не понял.
Другой язык чего? Человеческий? Программный? J2EE Это Java Enterprise Edition. Это исключительно JAVA. С локализацией к человеческому языку проблем нет. i18.
Среда. Это что? Операционка? Ну так JVM есть на большинстве ОС. Пользовательский интерфейс? Так тут тоже все нормально. EJB предполагает хоть текстовый (например кассовый аппарат) хоть графический (GUI скорее на JAVA), но лучше всего WEB. А браузеры на любой ОС есть. Я когда начинал проект, в конторе были древние маки на комнях 68 серии, потом G3/4 и писюки. Три филиала по Питеру и предполагаемый в нерезиновке. Свое производство... Каналы связи - роботикс модем Все работало.

[ronin]

Другой язык чего? Человеческий?

другой язык программирования/другая IDE

[vada]

другой язык программирования/другая IDE

Только JAVA.
Смена IDE немного напрягает. Хотя в них стандарт EJB нормально реализован. Некоторые фичи лучше, некоторые хуже. Где-то удобнее, гбе-то генерится лучще... Свои плюсы, свои минусы. Переперать проект из одной в другую немного напряжно, но можно. Но зачем этот головняк.

[WAYFARER]

Заблуждение. Управленческие проекты и документооборот одинаковые как блины. Содержат определенный набор блоков и работают одинаково.

Это вы не в курсе. Перекладывать бизнес-логику на SQL сервер это тупиковый путь в никуда. Давно доказано. При смене, иногда, даже версии SQL перестает работать. Про перенос на другой SQL даже не говорю. Проекты такого уровня, как правила, нуждаются в масштабировании. SQL сервер частенько становится слаб для задачи. Опять же еще один язык программирования в проекте.

Доказано вами?В системе, которую я на данный момент поддерживаю 611 таблиц, специально даже посмотрел, не считая временных таблиц, которые создаются в схеме пользователя, вся логика целиком положена PostgreSQL и написана на PL/pgSQL и немного pl/java, там же хранятся пользовательские формы и настройки, отчеты. Так вот - при изменении каких либо бизнес процессов, я могу перестроить систему зачастую просто несколько раз кликнув мышью не перебегая к программированию вообще.
Так же занимаюсь Парус 8 - там та же история.

А чего вы улыбаетес? Именно так. Например в фреймворке Hibernate я просто указываю в контексте что у меня теперь SQL сервер не MySQL а PostgreSQL или DB2. Все! Вообще не имею деля с кодом SQL.

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

Заблуждение. Управленческие проекты и документооборот одинаковые как блины. Содержат определенный набор блоков и работают одинаково.

Абсолютно неверно. С таким подходом практически отпадает смысл АСУП. Любая разработка в данной отрасли начинается с анализа и моделирования бизнес-процессов предприятия, которые везде различны. Задача - добиться максимальной эффективности. Но это я уже говорю ни как программист, а как управленец.