Добро пожаловать в форум, Guest  >>   Войти | Регистрация | Поиск | Правила | В избранное | Подписаться
Все форумы / Сравнение СУБД Новый топик    Ответить
Топик располагается на нескольких страницах: Ctrl  назад   1 [2] 3 4   вперед  Ctrl      все
 Re: Visual FoxPro 7 vs Power Builder 9  [new]
Alex Antipenko
Member

Откуда: Ukraine, Lviv
Сообщений: 110
Согласен с Crip , а может действительно попробуй C#.
18 июл 03, 10:29    [266820]     Ответить | Цитировать Сообщить модератору
 Re: Visual FoxPro 7 vs Power Builder 9  [new]
funikovyuri
Member

Откуда: Симферополь
Сообщений: 4045
2ALL: насчет C#. Вот что я считаю его минусами в данной ситуации:
- высокая квалификация разработчика - я имею ввиду что незачем, да и не всегда возможно брать спеца для разработки каких-то тривиальных задач - разработку GUI считаю как раз такой задачей - ведь для ее решения есть специальные инструменты(PB) в которых все стандартные сценарии работы уже отшлифованы.
- высокая квалификация программистов сопровождения - разрабатываемую систему после меня будут развивать. При ее реализации на С# для этого потребуется намного более квалифицированный специалист (читай дорогой) чем при реализации на VFP/PB.
- C# - зеленый язык, и еще мало кто имеет достаточный опыт проектирования на нем
- я не в восторге от RAD возможностей VS.NET - с точки зрения написания клиентов к БД. Обсуждаемы мной продукты имеют куда более развитую инфраструктуру в этой области. В этом я полностью согласен с ACRUS - есть инструмент(PB например) - легко и красиво решающий задачу написания DB GUI. Для всего остального этот инструмент поддерживает возможность использования компонентов созданных с помощью других инструментов через какую-либо компонентную модель - в данном случае это .Net

2Alex Antipenko: Да действительно - можно сказать что мне его навязывают.
Существующая система написана на FoxPro 2.6. Но так или иначе решение за мной и я занимаюсь анализом все за и против.
18 июл 03, 11:02    [266879]     Ответить | Цитировать Сообщить модератору
 Re: Visual FoxPro 7 vs Power Builder 9  [new]
Crip
Member

Откуда:
Сообщений: 2490
2funikovyuri
Мне кажется, что PB куда более прост как RAD средство, чем фокс. А по поводу квалификации я с вами не согласен,сложность программирования приблизительно одинакова...Хотя соглашусь, что программисты на фоксе стоят дешевле,но это всего лишь из-за того , что упал спрос на них...
18 июл 03, 12:08    [267039]     Ответить | Цитировать Сообщить модератору
 Re: Visual FoxPro 7 vs Power Builder 9  [new]
ASCRUS
Member

Откуда: МО Электросталь
Сообщений: 5994
Кину в общую корзину еще про PB:
1. Доступ к данным DataWindow организован в виде 2-мерного массива

// Доступ к записи 100 и полю 2
dw_Data.object.Data[100, 2] = 1

// Доступ к записи 100 и полю Number
dw_Data.object.Data[100, 'Number'] = 1

// Доступ к записи 100 и полю Number
dw_Data.object.Number[100] = 1

// Ну и т.д. - еще много способов ...

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

2. Expression в DataWindow - очень похоже на принципы Crystal Report. То есть на любое свойство контрола или поля DataWindow спокойненько можно впихнуть скрипт, который в зависимости от условий будет определять значение свойства. Допускается использование функций, написанных вами. Простой пример мощности такой технологии -берем поле Name, на свойство Background Color вешаем следующий Expression:

if( Value[-1] < 0, rgb( 255, 0, 0), rgb( 255, 255, 255 ) )

В итоге в представлении DataWindow поле Name будет выделятся красным цветом, если значение поля Value предыдущей строки меньше нуля (!!!). Думаю если иметь фантазию, то Expression применение не малое найдется как в формах, так и отчетах DataWindow. С учетом того, что DataWindow позволяет программе подсунуть любой Expression и он его выполнит, он еще является некоторым подобием легендарной макроподстановки фокса.

3. DataWindow изначально работают по технологии кэшированных изменений, причем самое похожее к нему, что я видел по принципам работы - это DataSet из .NET . Хотя на самом деле мне в PB больше нравиться - все гораздо умнее сделано, особенно если вспомнить вышеуказанные здесь буфера. Радует, что PB изначально очень граммотно получает данные и отсылает их изменения на сервер. Можно ручками настроить принципы сохранения измененных данных даже для сложных, казалось бы не редактируемых запросов. Identity поддерживается нормально. Также есть возможность проводить изменения в БД посредством указанных хранимых процедур. Все SQL скрипты элементарно перехватываются в специально созданных для этого событиях, так что сделать для клиента SQL монитор - пару строк кода, еще можно перехватывать SQL скрипт изменения записи, который PB уже сформировал, но еще не послал и даже его поменять или дописать по необходимости.

4. Поддержка зашаренных DataWindow очень мощная технология, которая позволяет какому то DataWindow ссылаться на данные, содержащемся в другом DataWindow. Что мы с этого имеет - легко можно на форму кинуть DataWindow в виде представления Grid, плюс сделать возможность вызывать дополнительное окно редактирование с представлением FreeForm для определенной записи. Причем данные для обоих DataWindow будут общие, а вот текущая запись у каждого своя и можно спокойненько для каждой требуемой записи создавать свое окно редактирования. Еще плюсик - делаем 2 DataWindow на один источник данных - один в виде грида, другой в виде отчета. Отчет шарим на грид. В итоге меняем данные в гриде, отчет (или график например) на автопилоте тут же пересчитывается. Получили редактируемый отчет. Данные кстати прекрасно экспортяться, так что никто не мешает сохранить записи на диск, потом в любой момент восстановить.

5. О встроенном SQL уже упоминали, что он пишется прямо как код программы и соотвествующе компилируется и проверяется на синтаксис, что является несомненным преимуществом. Однако еще замечательно, что SQL в PB позволяет писать скрипты без описания параметров запросов:

int id = 10
string name

select name
into :name
from table
where id = :id;

MessageBox( 'Name from ID = 10', Name )

Теперь представьте, что можно с этим сделать, особенно если вспомнить, что помимо явного описания скрипта PB поддерживает динамический SQL и работу с курсорами.

6. PowerScript забавный конечно язык - этакая помесь Basic и Java (да да, больше во многом похоже на Java, а не Си). Непривычный сначала, но как оказывается очень удобный. Писать на нем графические приложения или визуальные компоненты конечно не стоит, зато вот под создание клиентских частей он очень даже неплохо продуман. Тут не только языки до кучи смешаны, но и технологии тоже - ООП мирно уживается с процедурными элементами программирования, сборщик мусора не мешает самому программисту по необходимости удалять обьекты, массивы мирно уживаются и так же часто используются как коллекции, данные можно хранить как в структурах, так и полях обьектов.

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

События это отдельный разговор - во всех языках программирования событие - это оповещение подписчиков от некоего класса о произошедшем действии. В PB событие - это с точностью до наоборот - действие некоего класса на вызов его события кем то. События могут наследоваться, однако в отличие от наследований в методах классов порядок выполнения события идет от предка к наследнику. Второе отличие событий от методов класса - разрешается их динамический вызов, который в отличие от динамического вызова метода класса (он тоже есть, правда его правильней назвать отложенный вызов) не приведет к ошибке выполнения. Пример:

PowerObject obj
// ... тут на кого то его указали

// Вызываем у обьекта предполагаемую функцию GetItem.
// Получим ошибку компиляции
obj.GetItem()

// Вызываем отложенно функцию GetItem.
// Если ее нет, то получим ошибку во времени выполнения.
obj.dynamic GetItem()

// Вызываем у обьекта предполагаемое событие e_GetItem
// Получим ошибку компиляции.
obj.event e_GetItem()

// Вызываем у обьекта отложенно событие e_GetItem
// Никаких ошибок не получим, если его нет
obj.dynamic event e_GetItem()

// Вызываем у обьекта указанное событие, в данном случае e_GetItem
// Никаких ошибок не получим, если его нет
obj.triggerevent( 'e_GetItem' )

Теперь самое главное - в PB для выполнения функций и событий поддерживается очередь (!!!), т.е. их отложенное выполнение. Так что если например во время выполнения кода события из него необходимо вызвать некое действие или событие, которое противоречит выполяемому событию и должно выполниться только после окончания всех текущих действий, пишем:

obj.post funcName()
obj.post event eventName()

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

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

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

Так же если проект очень крупный, тиражный и предполагается его быстрое динамическое развитие для каждого клиента, то имеет смысл этап "Б" усложнить до уровня системы, имеющей свою IDE с дизайнерами DataWindow (легко реализуется засчет того, что DataWindow спокойно можно создавать во время выполнения и хранить где угодно, хоть в БЛОБах). Так же такая система должна поддерживать систему plug-in (легко реализуется засчет возможностей динамического подключения библиотек и исследования их содержимого).

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

P.S. Для описания использовался PB версии 8.0 . Что там они придумали в 9-ой версии, понятия не имею.
18 июл 03, 12:21    [267079]     Ответить | Цитировать Сообщить модератору
 Re: Visual FoxPro 7 vs Power Builder 9  [new]
funikovyuri
Member

Откуда: Симферополь
Сообщений: 4045
придумали вот это
Click on a topic for more information. Then use the Browse buttons on the Help window or the hot links to navigate.

· DataWindow XML support
· PowerBuilder Document Object Model
· PowerBuilder Native Interface
· JSP targets
· Web services for JSP clients
· Web services for Windows clients
· EJB clients for third-party application servers
· XML and CSV import and save
· Saving as PDF and XSL-FO
· The OrcaScript language

· PowerBuilder Runtime Packager
· PowerBuilder Resource Monitor
· Source control enhancements
· DataWindow enhancements
· PowerScript enhancements
· Debugger enhancements
· Database connectivity enhancements
· Miscellaneous enhancements
18 июл 03, 12:37    [267120]     Ответить | Цитировать Сообщить модератору
 Re: Visual FoxPro 7 vs Power Builder 9  [new]
Pavel
Member

Откуда: Кемерово
Сообщений: 2435
ASCRUS, после твоего повествования мне захотелось поставить и покопать PB. Вполне серьезно. Спасибо.
18 июл 03, 12:37    [267121]     Ответить | Цитировать Сообщить модератору
 Re: Visual FoxPro 7 vs Power Builder 9  [new]
funikovyuri
Member

Откуда: Симферополь
Сообщений: 4045
2ASCRUS: огромное спасибо! Ждал вашего ответа
18 июл 03, 12:39    [267127]     Ответить | Цитировать Сообщить модератору
 Re: Visual FoxPro 7 vs Power Builder 9  [new]
Ermak
Guest
"ИТОГО:
есть система( т.е. будет ) - точнее это АБС
есть много отчетов
отчеты должен иметь возможность создавать специалист средней квалификации - при этом бысто и удобно(для него)
не хотелось бы без необходимости вносить гетерогенность в интсрументы разработки - т.е. если я предпологаю такой интсрументарий
Power Designer + MS SQL + PB/VFP( клиент ) + C#( какие-то нетривиальные компоненты - то что на PB/VFP делать не удобно )
То мне бы не хотелось еще брать и программиста на С!"

Что ж разумное решение.
Я бы посоветовал бы Вам, хотя бы посмотреть на те демо примеры отчетов, которые можно делать с помощью технологи DataWindow.

Кроме PB, DataWindow имеется в таком продукте Sybase, как InfoMaker.

Кроме того можно скачать с www.sybase.ru (www.sybase.com) evaluation version PowerBuilder (~90 Mb в zip-файле).
18 июл 03, 12:39    [267128]     Ответить | Цитировать Сообщить модератору
 Re: Visual FoxPro 7 vs Power Builder 9  [new]
funikovyuri
Member

Откуда: Симферополь
Сообщений: 4045
2Ermak: уже сделано :) Сижу - тащусь.
Только вот с документацией проблемы - мало ее.
Так что читаю книгу о PB4( нашел за 5р ) и его родную документацию.
18 июл 03, 12:44    [267138]     Ответить | Цитировать Сообщить модератору
 Re: Visual FoxPro 7 vs Power Builder 9  [new]
ASCRUS
Member

Откуда: МО Электросталь
Сообщений: 5994
Тем кто постоянно проектирует клиентов БД для сложных и больших проектов настоятельно рекомендую посмотреть в сторону PB. Самое плохое, что документации почти ноль. Для московских программистов или бывающих здесь проездом могу поделиться компактом с 2 книжками по PB (пересланными мне с Украины), правда отсканенными в jpg и по 5 и 6 версиям PB, но как говориться на безрыбье и рак рыба :) Так же их можно скачать с ftp одного хорошего человека, который согласился их выложить:

в основном включен вечером и ночью
shanson.no-ip.info
login - power
pass - builder

он правда из германии, поэтому я не знаю, насколько у них вечер отличается и ночь от наших :)

Со мной же лучше всего связаться для начала по моему мылу.
18 июл 03, 12:48    [267147]     Ответить | Цитировать Сообщить модератору
 Re: Visual FoxPro 7 vs Power Builder 9  [new]
Укьфл
Guest
"Только вот с документацией проблемы - мало ее.
Так что читаю книгу о PB4( нашел за 5р ) и его родную документацию."

Из того что идет вместе с PB обратите внимание на:
- "Application Techniques"
- "DataWindow Programmer's Guide"

Кроме того полный комлект документации в формате PDF (на English)
можно тащить с http://sybooks.sybase.com/pb.html
18 июл 03, 14:11    [267300]     Ответить | Цитировать Сообщить модератору
 Re: Visual FoxPro 7 vs Power Builder 9  [new]
funikovyuri
Member

Откуда: Симферополь
Сообщений: 4045
2Укьфл: отлично! спасибо
18 июл 03, 14:37    [267386]     Ответить | Цитировать Сообщить модератору
 Re: Visual FoxPro 7 vs Power Builder 9  [new]
Crip
Member

Откуда:
Сообщений: 2490
Мастера рекламы блин.
Прочел пост ASCRUS и понял, что в фоксе почти все это есть и даже больше.
Но рекламировать ломает.
18 июл 03, 14:57    [267446]     Ответить | Цитировать Сообщить модератору
 Re: Visual FoxPro 7 vs Power Builder 9  [new]
funikovyuri
Member

Откуда: Симферополь
Сообщений: 4045
2Crip: наоборот - давай точку зрения спеца по Fox'у.!
18 июл 03, 15:12    [267492]     Ответить | Цитировать Сообщить модератору
 Re: Visual FoxPro 7 vs Power Builder 9  [new]
Crip
Member

Откуда:
Сообщений: 2490
В плане языка мне кажется что у фокса все что нужно есть и даже больше чем надо. По крайней мере в PB ничего такого, чего нет в фоксе я не увидел, судя по постам.
Но...Как RAD фокс думаю уступает PB. Что-бы приложение получилось работоспособным никакие визарды и генераторы не подойдут. Все нужно ручками писать и знать некоторые подводные камни.
Вот если это все написать , то уже да. Благодаря тому, что практически все что есть в среде доступно в рантайме сопровождение очень сильно облегчается.

И еще повторюсь MS плавно пытается увести людей с фокса на .NET. Фокс конечно еще будет суппортиться по крайней мере лет 10, пока пользователи не поймут , что он уже не чем от .NET не отличается
Хороший продукт, но без большого будущего :( Правда почему-то популярность его гораздо меньше, чем он того заслуживает. Видать то , что в прошлом было написано куча корявых прог под ДОС испортило.

Мне вот только не верится, что в PB все так легко и просто и вообще ничего писать не надо. Все за вас сделают. Ни какой генератор головы ведь не заменит. И в любой работе самое главное это решение поставленной задачи, а как это должно мало волновать заказчика...

2NNN
Такое ощущение , что ты уже поостыл к VFP?
18 июл 03, 15:27    [267548]     Ответить | Цитировать Сообщить модератору
 Re: Visual FoxPro 7 vs Power Builder 9  [new]
ASCRUS
Member

Откуда: МО Электросталь
Сообщений: 5994
Crip
Все есть везде. Другое дело какой ценой это все достается. Для меня корректное сравнивание инструментов - это в первую очередь не их возможности, а заложенные в них концепции правил проектирования и реализации продуктов. В PB я считаю сама модель правил проектирования проектов правильная, все логично, продуманно, никаких прикруток и довесок, строгая ориентация средства только на построение клиентов релляционных БД. Может ли VFP похвастаться тем, что он изначально был ориентирован на работу с SQL БД, что в нем все изначально продуманно и нет никаких "левых" решений в виде прикруток и довесок, противоречащих его изначальным концепциям ? Я VFP не видел, поэтому ответ за Вами. Однако в свое время я очень много работал с ForxPro 2.0-2.5 и хорошо зная как и с чем он работал сильно сомневаюсь, что он стал таким вот удобным средством для проектирования сложных клиентских приложений. Я не сомневаюсь, что MS вставил в VFP все, что только имеет громкое имя и может принести деньги - ООП, интернет, 3-звенки и т.д., но я знаю, к чему это приводит - наслоению технологий, путанице и возрастанию размера и читабельности кода.

PB изначально был спроектирован под клиент-серверные системы, с поддержкой принципов ООП, SQL, кэшированных изменений и мощным механизмом полученных с БД обработки и отображения данных. Правильная модель его реализации и явилась залогом того, что любые его новые возможности органично вписываются в него, позволяя оставлять те же концепции проектирования программ, расширяя их новыми функциональными возможностями.
FoxPro был изначально спроектирован под файл-серверные системы, как клон процедурного D-Base языка. По моему этим сказано все. В свое время я писал на FoxPro крупные проекты, которые до сих пор крутяться и прекрасно работают. Однако времена меняются и считающиеся тогда крупные проекты семечки по сравнению с тем, чем я занимаюсь теперь, что привело к моему переходу с файл-серверных на клиент-серверные технологии и соотвествующе и выбору других средств проектирования клиентов.

Пока писал ... новый пост от Вас появился. Прокоментирую:

Что-бы приложение получилось работоспособным никакие визарды и генераторы не подойдут
Ни о каких генераторах и визардах в PB речи я не вел. Их там особо и нет. Все дело в правильной модели PB, отсюда и мало кода.

И еще повторюсь MS плавно пытается увести людей с фокса на .NET
Насчет увести с фокса на .NET - чисто маркетинговый ход. Я пока не увидел чего то револлюционного в .NET, что действительно бы облегчило работу по созданию клиентских приложения. Я бы даже сказал усложнило на самом деле, так как компонентая модель ООП конечно универсальна, но усложняет проектирование и кодирование узконаправленных приложений, хотя оставляет широкий выбор расширения средств. Думаю зависимость между универсальностью, скоростью и качеством величина постоянная для любого средства и чем то жертвовать приходится всегда. В PB ООП обрезан по самое не хочу - там он реализован ровно настолько, чтобы позволить проектировать иеархию повторно используемых решений в проекте и писать 3-звенки. Больше на нем ничего не сделаешь. В C# можно делать все, но только через ООП и соотвественно классы и компоненты, что приводит к скатыванию кода до уровня управления классами, понижению его читабельности и возникновению многих проблем при решении узкоспециализированных задач, решения которых гораздо спецефичнее, чем набор предлагаемых классов и компонент для решения общего круга задач.

Видать то , что в прошлом было написано куча корявых прог под ДОС испортило
Извините - но насчет кучи корявых прог под ДОС - это необоснованный выпад. Куча корявых прог есть на любом средстве программирования и я бы сказал ДОСовый Fox как раз может гордиться тем, что стал "учителем" очень многих сейчас уважаемых и проффесиональных программистов, как кодеров, так и проектировщиков БД. Ради интереса поспрашивайте на форумах SQL.RU, сколько сейчас "крутых" программистов с Фокса слезло - думаю статистика Вас удивит. Заодно можете спросить, почему они с Фокса слезли в свое время.

И в любой работе самое главное это решение поставленной задачи, а как это должно мало волновать заказчика...
Как решается задача очень даже должно волновать заказчика. Ведь ему потом на этом продукте работать и возможно своими силами сопровождать не один год в условиях постоянно динамически изменяющихся внешне и внутре экономических условий. Вам не кажется странным, что не только в мире, но и у нас очень много крупных проектов реализовано с использованием PB и проекты уже годами сопровождаются силами внутренних АСУ (хоть в тех же крупных американских банках) ? Причем никто из них особо о смене инструмента не говорит, не смотря на то, что некоторые проекты были написаны 10 лет назад. И зарплаты PB программистов там стабильно держаться на высоком уровне (да и у нас кстати тоже, правда по причине отсуствия таких программистов). Думаю это хороший показатель в пользу того, что проекты на PB легко реализуются и в дальнейшем так же легко сопровождаются.

P.S. Кстати не знаю насколько это правда, но читал, что PB выступил в роли дедушки Access и VB, чему немного верю, с учетом того что формы Access уж очень во многом напоминают DataWindow из PB, который был сделан гораздо раньше, чем Access. PowerSoft-овцы утверждают, что Билли лично к ним приезжал, смотрел на их разработки и в первых версиях Access и VB участвовала команда разработчиков PB, в том числе и Watcom-вцы, которые в свое время разработали по заказу PowerSoft язык PowerScript и виртуальную машину PBVM. Вот такие вот сплетни ходят по интернету :)
18 июл 03, 16:20    [267674]     Ответить | Цитировать Сообщить модератору
 Re: Visual FoxPro 7 vs Power Builder 9  [new]
Ermak
Guest
"Мне вот только не верится, что в PB все так легко и просто и вообще ничего писать не надо. Все за вас сделают. Ни какой генератор головы ведь не заменит."

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

" И в любой работе самое главное это решение поставленной задачи, а как это должно мало волновать заказчика... "

Совершенно верно ибо, ни PB, VFP заказчик на хлеб намазывать не будет.
18 июл 03, 16:25    [267682]     Ответить | Цитировать Сообщить модератору
 Re: Visual FoxPro 7 vs Power Builder 9  [new]
Crip
Member

Откуда:
Сообщений: 2490
Ни каких прикруток и довесок. Довеском является лишь поддержка совместимости в 2.x. Все остальное было заложено еще в 3-й версии.
Ну а сравнение с Access вообще выглядит странно. С моей точки зрения Access является примером продукта с которым по началу все легко и просто , а когда нужно писать что серьезнее начинаются серьезные проблемы. Как язык программирования фокс выглядит гораздо более ориентированным под профессионального разработчика нежели Access.
Меня вообще удивляет подход многих людей не знакомых с VFP. Такое ощущение , что данные товарищи преднамеренно пытаются показать свою сравнительную крутизну , на том лишь основании , что используют другое средство проектирования. То есть кто пишет на VFP - дурак. А тот кто пишит на Delphi или PB - юный Страуструп... Потрясающая логика...
Больше я сюда не пишу ничего , так как дальше диалого в таком русле считаю бессмысленным
До свидания...
18 июл 03, 16:32    [267696]     Ответить | Цитировать Сообщить модератору
 Re: Visual FoxPro 7 vs Power Builder 9  [new]
ASCRUS
Member

Откуда: МО Электросталь
Сообщений: 5994
Crip
А меня наоборот удивляет подход людей, знакомых только с VFP - когда им говорят, что есть и другие технологии (заметьте я не зря очень часто повторяю именно слово другая технология, а не язык или средство) и которые сразу рвуться в бой, даже не ознакомившись с идеями, которые пытаются до них донести собеседники - прям какой то комплекс неполноценности, который приводит к тому, что на любое сравнения VFP с чем то все обижаются и говорят, что их назвали дураками.

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

Я например Access рассматриваю не как язык программирования, а как настольную БД и считаю для своих целей он очень даже ничего. Если кто то на нем и пытается крупные проекты писать - так это проблема не Access, а "светлой головы" программиста.

Извините, если чем обидел, задачи такой во всяком случае перед собой не ставил. Крутизну свою доказывать не стал бы - ее уровень я и сам неплохо и точно могу оценить по кол-ву и обьему запущенных проектов :)

Просто хотелось малость расширить кругозор коллег, так как сам собственно говоря вполне недавно перелез с Delphi на PB и был страшно огорчен, что раньше никогда о нем ничего не слышал и не видел и считаю что очень много из за этого потерял :)

С чем считаю тему закрытой и говорю всем до свиданья :)
18 июл 03, 16:59    [267757]     Ответить | Цитировать Сообщить модератору
 Re: Visual FoxPro 7 vs Power Builder 9  [new]
NNN
Member

Откуда:
Сообщений: 2141
2Crip

Хоть ты и обещал больше сюда не писать, но надеюсь прочитаешь.

> Такое ощущение , что ты уже поостыл к VFP?

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

ЗЫ наверное у меня просто психологическое состояние на грани - напарник в отпуске, грузят asp, дома комп скоро накроется и проч, поэтому стараюсь посещать только форумы №37 и №16, так, вместо отдыха:)
18 июл 03, 17:03    [267765]     Ответить | Цитировать Сообщить модератору
 Re: Visual FoxPro 7 vs Power Builder 9  [new]
Ermak
Guest
2 Crip.
Кончайте обижаться и дуться, ну не в детском же мы саду право.

ASCRUS прямо сказал, что: "Я VFP не видел, поэтому ответ за Вами. Однако в свое время я очень много работал с ForxPro 2.0-2.5 и хорошо зная как и с чем он работал сильно сомневаюсь, что он стал таким вот удобным средством для проектирования сложных клиентских приложений"

Ничего оскорбительного я не заметил.

Также согласен с его же мыслью: "Все дело в правильной модели PB, отсюда и мало кода". Но, подчеркиваю думать от этого не приходится меньше, ни капельки. Просто когда отпадает головная боль, по поводу как вернуть на клиента Result set, забодай его комар, освобождается время и силы на решение задачи эффективного представления и обработки полученной информации.

Немножко отвлекаясь от темы.

В нашей организации у начальника продавцов новая забава, попытка найти для себя подходящую CRM. Сразу хочу предупредить, что это человек который четко знают что уму нужно от CRM, и мне в этом приходится ассистировать, в смысле развернуть очередную Evaluation or Demo version на ПК. Просмотрел уже более 10 различных систем, но...
В подавляющем количестве систем для представления данных из БД используется Grid для отображения списка + Free form для ввода и редактирования строки из Grid. Да и grid какой-то унылый и невзрачный. То, проблемы с фильтрацией, то проблемы с сортировкой, то отсутствие режимов просмотр/правка. Отсутствие экспорта результатов, невозможность печати Grida, невозможность Preview и т.д.

Грустно это. Откуда такая скупость в средствах представления данных, если приложение ориентировано на работу с СУБД?

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

Именно поэтому я в своё время выбрал PB. За его возможности взаимодействия с различными релционными СУБД. Подчеркиваю различными.

В июньском номере Windows & .net magazine/re (www.winnetmag.ru) есть неплохая статья "Эволюция технологий доступа к данным", прочтите её. Краткий анализ технологий Microsoft в этом вопросе показывает их движение к технологии аналогичной DataWindow. Ну не обессудте - это именно так. С песнями, плясками, бешенным маркетингом, но движение идет в том же направлении, что уже имеется сейчас в DataWindow.
18 июл 03, 17:20    [267796]     Ответить | Цитировать Сообщить модератору
 Re: Visual FoxPro 7 vs Power Builder 9  [new]
c127
Guest
2 funikovyuri
>есть много отчетов
отчеты должен иметь возможность создавать специалист средней квалификации - при этом бысто и удобно(для него)
не хотелось бы без необходимости вносить гетерогенность в интсрументы разработки - т.е. если я предпологаю такой интсрументарий

Посмотри датавиндовс. Дополнительных средств вроде кристал репортс не требуется вообще. Очень удобно.

2 Crip
>Прочел пост ASCRUS и понял, что в фоксе почти все это есть и даже больше.

Сила DW ИМХО не в том, что он позволяет представлять данные в виде двумерного массива, а в том, это что сложная форма внесения/просмотра данных и одновременно готовый к печати документ. Можно даже всякие графики и диаграммы строить. Это основное отличие от других RAD средств, с которыми я работал.

2 Ermak
>В данном случае если надоело ждать пока что-то там выберется, допустим заказали с сервера на клиента 10 млн записей, то с помощью dbCancel() можем этот процесс прервать.
К моему великому сожелению ASA 7 этого не умеет.

Может я чего-то недопонял, но можно прервать retrieve из события retrieverow. Я использую. Если интересно - напишу подробней.
19 июл 03, 02:11    [268235]     Ответить | Цитировать Сообщить модератору
 Re: Visual FoxPro 7 vs Power Builder 9  [new]
Sergey Ch
Member

Откуда: Благовещенск
Сообщений: 8894
Жаль, что ничего толком не могу сказать в поддержку FoxPro (уж очень много работы в последнее время .

Про PB только слышал немного, листал учебник - примеры сразу отпугнули длинными распечатками примеров с необычным синтаксисом. (Обратил я на это средство внимание, так-как в Австралии требовались тогда программисты под этот инструмент).

Для глубинки вполне хватает FoxPro. В Интренете вполне хватает связки VFP+W2K+ASP+VB+WebServices (да еще файл-сервер Novell). Да в принципе, я об этом уже писал на этом форуме, а выход в Интеренет тут: Здесь все пронизано FoxPro - несколько проектов (начиная от форума, системы заказов на ремонт техники, строительного и компьютерного магазинов, заканчивя оторвонным центральным складом, котрый виден только из прикладных программ, но осуществляет обмен данными через IIS)... Если бы не FoxPro, то реализовать данный проект было бы на мой взгляд одному человеку просто не по силам...

Так что мой вклад в дискуссию - FoxPro проверенный на практике инструмент для быстрой разработки и надежной работы приложений (в купе с автоматизацией почти любого бизнеса, была бы у Вас фантазия и мозги). Ну а то, что FoxPro не модный сегодня, так это пройдет...

Чем еще хорош FoxPro - сделал, отладил и забыл. Мои многие задачи крутятся годами без вмешательства... Если только любители делфи не начинают стирать DBF файлы Но о вредительств врагов FoxPro надо говорить в топике по этике и конкурентной борьбе
20 июл 03, 07:11    [268501]     Ответить | Цитировать Сообщить модератору
 Re: Visual FoxPro 7 vs Power Builder 9  [new]
NNN
Member

Откуда:
Сообщений: 2141
2ASCRUS

> А меня наоборот удивляет подход людей, знакомых только с VFP - когда им говорят, что есть и другие технологии..

Хорошее замечание, но надо уточнить, что на людей, знакомых только с VFP обычно смотрят как на людей, знакомых только с FoxPro 2.0 и при этом ссылаются на личных опыт. Да откуда я могу знать личный опыт других? Я сидел на одном проекте под FPD 2 года, а другой за это время может наклепал пару десятков однотипных программ. Вот и получается одним приходится решать неординарные задачи и лесть в дебри, а другие лихо освоив метод copy-paste кричат об каком-то опыте.
Не хочу никого обижать, но ваше мнение - это ваше мнение. Был у меня знакомый дельфист, которого перевели под фокс. Он мне показал 20 вещей, которых якобы нет в фоксе. Потом выразил неудовольствие, что это типа намного сложнее и логика совершенно другая. Пришлось показывать вещи, которые в фоксе реализованы лучше. Паритет был уствновлен, больше мы с ним не спорили, а спокойно работали в паре.

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

Странное замечание, особенно в адрес Crip.
Отвечу за себя, развивать кругозор будешь поневоле, хороших книг и статей по фоксу в последнее время мало, поэтому и читаем все подряд по подходящей тематике. Жалко времени на пощупать руками обычно не хватает, отсюда - полное отсутствие опыта, поэтому молчим и говорим только о том, в чем разбираемся. Да и о недостатках, если и пишут, но очень мягко. А в нашей работе знание недостатков часто важнее знания достоинств.

2Ermak

> Грустно это. Откуда такая скупость в средствах представления данных, если приложение ориентировано на работу с СУБД?

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

> Именно поэтому я в своё время выбрал PB. За его возможности взаимодействия с различными релционными СУБД. Подчеркиваю различными.

ИМХО сейчас очень трудно найти средство, которое этого делать не умеет.

> В июньском номере Windows & .net magazine/re (www.winnetmag.ru) есть неплохая статья "Эволюция технологий доступа к данным"

Не обижайтесь, зайдите на http://www.louvre.fr/ , там есть обзорные статьи о музее, а есть подробная история создания Джоконды. Я к тому, что подобные 'как посмотреть Лувр аз пять минут' можно встретить на каждом углу.

> Краткий анализ технологий Microsoft в этом вопросе показывает их движение к технологии аналогичной DataWindow.

Ну не обессудьте, но то что я читал об ADO.NET напоминает мне de javu. Кажется я это уже видел еще в VFP3 или даже в FP2. Если же учитывать, что OLEDB использует технологию, заимствованную из FoxPro (только пишут об этом редко и неохотно), а ADO.NET - это очередное продложение, то может быть давно пора признать, что идеи д-ра Фултона живут и побеждают?

ЗЫ из этого топика для себя я сделал такой вывод: VFP явно проигрывает PB в скорости разработки. Но я не отношу VFP к RAD (конечно, оно может быть использовано в этом качестве, но очень не советую, особенно в первое время) и если приложить некоторые предварительные усилия, то потом время написания приложений существенно сократится. Большая открытость , дает больший контроль, а возможность создания дополнительных библитек, используя FoxAPI, о чем писал Crip, позволяет решать задачи практически любой сложности.
Так что пишите на том, что хорошо знаете и в чем уверены. Ваши личные значния и опыт - самое большая ценность, отсутствие которой не компенсировать никакими суперсовременными технологиями.
20 июл 03, 09:23    [268507]     Ответить | Цитировать Сообщить модератору
 Re: Visual FoxPro 7 vs Power Builder 9  [new]
Ermak
Guest
К дискуссии подключаются интересные люди (NNN).

Хотелось бы узнать о VFP, как средстве разработки клиента несколько поподробнее, в частности:

- Какие инерфейсы доступа к данным поддерживает VFP?

- Если можно, то с Вашей личной оценкой, что хорошо, а что плохо реализовано?

- Доступ к каким SQL серверам будет эффективен при разработе клиента на VFP (будет здорово, если будут ссылки на собственный опыт)?

-У меня после чтения тутошних форумов сложилось ощущение (заметьте не мнение, а именно ощущение), что связка VFP + MS SQL2000 будет работать лучше, беспроблемнее, чем допустим VFP + SQL производства не Microsoft. Если это так, то почему, за счет каких механизмов, если не так, то почему такое мнение существует?

PS. Большая просьба ко всем участникам дискуссии,свои аллергические реакции на технологии, продукты, прошлый опыт, и родовую память обуздывать и не реагировать. Проявляйте максимальную корректность.
20 июл 03, 11:56    [268525]     Ответить | Цитировать Сообщить модератору
Топик располагается на нескольких страницах: Ctrl  назад   1 [2] 3 4   вперед  Ctrl      все
Все форумы / Сравнение СУБД Ответить