[delphicoding]

Добрый день!

С Delphi вообще не знаком. Программировал ранее на языке программирования с куда более "логически очевидным кодом" и в другой области прикладного программирования и графики. Так получилось, что попросили помочь - отредактировать старый проект Delphi + Firebird. Пытаюсь освоить... по началу всё как-то тупо и непривычно, утомляет всякая имхо неудобная фигня и лишние строки, непонятные приставки итд. Например, нужно добавить показ в таблице ещё одной колонки данных - пол дня вожусь хз как это сделать - колонку добавил, объявил в начале исходника, данные колонке из БД назначил, программа компилируется но колонка пустует... открываю файл БД там ещё тонна кода - ну таблицы понятно, тригеры понятно, но полно ещё каких-то процедур, доменов, индексов... Конечно, всё это нужно изучать, но всё же возможно вы сможете как-то помочь вначале...

1. Прошу профи посоветовать - как под Delphi 2009 + Firebird (+FIBplus +DevExpress +JVCL) наиболее легко и удобно с точки зрения логики и простоты понимания и отслеживания цепей процессов организовать работу с Firebird? Например, год назад вдруг потребовался MySQL - разобрался в нём за час! - научился создавать БД, таблицы, строки, определять типы данных, записывать данные, очищать, удалять, итд. Но в данном проекте видимо используется слишком большое кол-во шагов: создание переменной, определение типа переменной, создание процедуры для переменной, создание в интерфейсе компонент и назначение переменных, отсыл к общему блоку в Delphi работы с СУБД, взаимодействие с неким процедурами СУБД, получение, разбиение, итд. Можно ли упростить цепочку? Мне было бы намного проще: а) работать с визуальными копонентами автоматически объединяемыми в блоки (например, как в html создаётся блок с кнопкой Enter, а все поля заполняются и отправляются автоматически без необходимости каждое поле объявлять, обозначать, процедуры для него писать, без необходимости объединять все эти запросы, итд); б) работать с БД напрямую вручную - мне проще перечислить текстом 50 таблиц, чем разделять код программы на 10 различных типов кода (объявление, назначение, процедуры, функции, потом тоже самое опять в СУБД, итп), кроме того код не содержит почти никаих комментариев - тк непривычно и всё это вместе выглядит как каша!
Вот ещё пример, объект с выпадающим списком называется TJvDBLookupCombo и в нём есть возможность напрямую указать данные из БД, а вот в колонках DevExpress так и не нашёл как указать напрямую нужные из БД таблицы-данные??

2. Можно ли как-то автоматически перевести весь проект на более удобный-простой метод общения с БД?

3. Возможно также есть возможность в настройках скрыть весь код автоматически генерируемый Delphi при работе с графическим интерфейсом (формами), чтобы отображался только код написанный вручную? Чтобы просто не мешал на первых порах...

4. Посоветуйте книги по Delphi + DevExpress + FIBplus + Firebird...

Заранее спасибо за подробные полезные ответы!

[Developer]

2. Найти компонент общения с БД покруче или написать свой слой в архитектуре программы для облегчения работы (я так делал при роботе с XML).
3. Не знаю насчёт настроек но я обычно делаю так: Основной класс программы пишу в отдельном файле, а в интерфейсе только связую парами строчек кода с основным обектом программы. Выходит довольно красиво (чтото наподобе Binding в WPF)

[lmikle]

В DevExpress все делается через свойство DataBinding (кажется так, нет под рукой что бы точно сказать). По архитектуре ничем не отличается от стандартных компонентов за исключением того, что вынесено в одну группу.

По поводу более удобного компонента... ну вообще FIBPlus опять же сделать в соответсвии с общей архитектурой DB-Aware компонентов. Так что та груда кода, на которую ты жалуешься есть чье-то творчество. В идеале, можно вообще обойтись без строчки custom кода, хотя для некоторого удобства порой надо использовать доп. сторки.

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

[delphicoding]

Уважаемые профи - будьте так любезны дать ссылки на простые примеры или возможно сможете написать сами небольшой пример вида:
БД Firebird с таблицей, триггером, доменом - форма в Delphi с таблицей FIBplus/DevExpress - всё это с наиболее правильной логической организацией взаимодействия Delphi-СУБД на ваш взгляд... чтобы лучше понять как делать правильно...

[antikiler]

Незнаю, может пригодиться. Вот и вот

[delphicoding]

Спасибо, прочитаю!

[delphicoding]

После нескольких дней ковыряния проекта, среда Delphi не особо радуют... :(

-1 Прежде всего кривые хрен знает откуда взятые названия терминов... например Unit - шозанах?! Оказывается это Code. А, что Form не может быть по-английски Unit?? это самый просто пример, таких примеров "странных названий" полно. Сильно мешает.

-2 Слабая стандартизация компонент, вот несколько блоков кода одного проекта с совершенно разным синтаксисом, хрен разберёшь что где как делать:

With spReport do begin (без "do" никак?)
close;

SQLs.SelectSQL.Text:='SELECT * FROM '+ProcName+'(:DATE_FROM, :DATE_TO, :source_id, :temp_ID, :USER_ID)'; (тут появилось двоеточие)

Params[0].Value:=pDateFrom; (почему параметры они тупо по циферкам не понял)
Params[1].Value:=pDateTo;

freport.Variables['Директор']:=''''+gDirector+''''; (оппа появились кавычки в огромном колве и даже плюсики, а переменная уже в квадратных скобках, оппа)

-3 удацкая конструкция взаимодействия с данными БД - нельзя просто написать хоть в коде, хоть в Value графического объекта значение вида "FBSQL.db.table.column" например "FBSQL.basa.COMPANY.DIRECTOR" или даже ещё проще "FBSQL.DIRECTOR", нет, нужно всё друг другу переназначить по 10 раз и завести новые переменные с абсолютно аналогичными названием типа:

gDirector:=GetParams('DIRECTOR','');
edDirector.Properties.Value:=gDirector;
SetParams('DIRECTOR',gDirector);
gDirector:=GetParams('DIRECTOR','');

-4 собственно о процедурах - нахрена их объявлять по два раза?! в начале и при запуске процедуры? какой смысл?!

type
procedure ShowReport(ProcName, ReportName, ReportType:string);

procedure ShowReport(ProcName, ReportName, ReportType:string);
begin
...
end;
end;

-5 наверно Delphi делали чтобы было легче программировать, например в пред пункте (ProcName, ReportName, ReportType:string) можно указать тип переменной не для каждой, а сразу для группы - типа удобнее же и быстрее! но в реальности это менее наглядно и приходится выискивать какого же собсвтенно типа одна из десятка переменных?! где же объявлялка там затерялась?!

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

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

-8 объекты на графической форме не только нельзя расположить точно по абсолютным значениям пикселей, а только относительно предыдущего объекта, но и нельзя создавать сетки привязки объектов по координатам - в результате сложные формы с кол-вом графических объектов более 30-50 задолбаться можно выравнивать, и нет блокировки от случайного движения мышкой - через раз выбирая объект слегка его дёрнешь куда-нить в сторону в итоге все разъезжаются...

-9 куча левых приставок вида spDirector, exDirector, TDirector, TfDirector итд... офигеть можно, зачем всё это?! Есть некие данные в БД назовём просто "FBSQL.DIRECTOR" также пускай будет переменная хранящая и передающая значение из БД "var.Director" если переменная назначена графическому объекту - пускай у него будет имя и свойства вида "obj.EditFiledDirector.Width" итп. Всё прекрасно видно, понятно и работать легко и ничего не перепутается! Тут же в Delphi бардак полный у всех однотипные имена и хрен поймёшь сразу что где и чем отличается от соседнего?! слишком много для одних данных разных переменных и объектов. Опять же не хватает параметра для всех переменных вида local/global - создал один раз переменную global и обращайся к ней напрямую из любого места проекта, а тут постоянно приходится указывать откуда эта переменная родом, где была заявлена - лишний код и груз.

-10 зачем нужен begin-end в каждой процедуре?! нельзя просто скобочками или типа того?!

procedure TfLocalReport.btPrintClick(Sender: TObject);
begin
fDesign:=false;
PrintReport;
end;

намного компактнее и проще для визуальной проверки было бы:

procedure TfLocalReport.btPrintClick(Sender: TObject) {
fDesign:=false;
PrintReport }



В общем пока вижу только, что в Delphi довольно легко сделать лёгкий проект, но разобраться в сложном проекте - охренеть. :(

Если можете чтото подсказать по повышению удобства работы в Delphi - было бы здорово!


PS Не ругайтесь - целый день ковырялся пытался исправить ошибку разработчика вытащить одно поле из БД которое он забыл вывести в отчёт - исправил несколько ошибок, оптимизировал код блока отчётов в почти два раза! всё что было работает... но нужное новое поле так в отчёте и не появляется.... мля... бесит! :wall:

[angvelem]

Читать и ещё раз читать. Большинство претензий или от непонимания, или ошибочны.

[lmikle]

Из действительных претензий - только 7.
Все остальное либо от незнания, либо от криворукости (и не только предыдущего программера).

Был проест на 100+ форм с кучей модулей и мегабайтами кода (всесте с dfm ). Над ним параллельно работало несколько человек. И ничего, все делалось быстро, код передавался по необходимости друг от друга.

Так что возвращайтесь мол.чел в C# или Java (на чем вы там до того писали, скорее C#) и не мучайтесь и не мучайте других своими стонами.

[delphicoding]

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

Из действительных претензий - только 7.
Все остальное либо от незнания, либо от криворукости (и не только предыдущего программера).
Так что возвращайтесь мол.чел в C# или Java (на чем вы там до того писали, скорее C#) и не мучайтесь и не мучайте других своими стонами.

Модератор так обязательно хамить? И нет, я работал не на C#/Java. Если все остальные "претензии не претензии" - подскажи лучше как их решить...

[delphicoding]

lmikle
Если это всё не проблемы - объясни пункты: 2 и 3 - почему такая разница и зачем это нужно? как наиболее лекго писать вызовы к БД (п.3)?
Как решить пункты 7 и 8?

[chainik]

А вообще- то ребята все мы говорим не о том.
Я много раз наталкивался на дискуссии на тему : какой язык лучше.
Очень многие хвалят C (и его модификации) Многие- Pascal (и его модификации, включая Delphi). Мне, например, очень импонирует незаслуженно забытый язык Modula- универсальный язык предназначен для системного программирования и для разработки встроенных систем. Язык академически строг и точен, не допускает никаких вольностей но и возможности для программирования предоставляет достаточно.
Великолепен язык ADA- этот язык разрабатывался специально по заказу Мин. Обороны США. Язык очень сложный, но если у вас хватило выдержки его изучить- вы не пожалеете. Оба они основаны на языке Pascal и их предшественнике- языке Algol.
Что же до языка С- то мой опыт ограничен. Я с самого начала столкнулся с присущими этому языку недостатками: нестрогой типизацией, отвратительным синтаксисом и неясностью кода. Вообще, клон Pascal дает чрезвычайно ясный самодокументирующийся код, не требующий комментариев.
Язык С- Хмм.... попробуйте разобраться в собственном коде допустим через полгода.
Но главное даже не в этом. Загоняя дискуссию в тему «а какой язык лучше» мы уходим от главного- а для чего собственно пишет программист?
Мой ответ- программист пишет для пользователя. А ему (пользователю) ровным счетом наплевать на каком языке написана программа. Просто она должна делать то, что он от нее ожидает. И это все.
Разумеется, не все. Дело в том, что программист- не просто наблюдатель, но и активный соучастник всего процесса. Именно программист должен до тонкости изучить работу данного отдела, понять все взаимосвязи и перевести их на язык, понятный компьютеру. А вот после этого- написать программу.
Я часто сталкивался с ситуацией, когда в общем- то неплохой программистский коллектив предлагал нам совершенно негодные программы. И это не потому, что они жулики. Нет, это грамотные молодые люди, недавно окончившие ВУЗ, знающие по 2-3 языка. Просто люди ни дня не работали в реальном производстве, не знают реальных потребностей и реальных трудностей, ну а заработать хочется...
Вот почему я всегда говорю, что лучший программист- это тот, который у вас работает.
В моей практике были примеры, когда казалось бы хорошо написанная программа проваливалась. Причин всегда было 2:
1- Я не угадал реальной потребности подразделения и моя программа оказалась невостребованной.
2- Не было политической воли руководства изменить структуру подразделения и взаимосвязи с другими подразделениями и внедрить эту мою программу.

Итак, завершая свое выступление, прошу модератора
1. Ввиду бесперспективности в дальнейшем не рассматривать запросы на тему «Какой язык лучше». Всегда лучше тот что ты лучше знаешь.
2. Перенести данную дискуссию в раздел «Бессмысленный треп»

[delphicoding]

chainik
Такой большой постинг у тебя и такой бессмысленный.
Название темы - вопрос по взаимодействию Delphi и Firebird, обсуждения "какой язык программирования лучше" - тут вообще нет, тк уже использован Delphi. Учись читать.

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