Darmowa i prosta biblioteka do SQLite

Hey,
Witam wszystkich w nowym, pięknym tygodniu :P

Chciałbym podszkolić swoje umiejętności operowania danymi z bazy danych. Najlepsza dla moich celów jest SQLite (ponieważ nie będę używał zaawansowanej składni SQL - najprostsze zapytania). Używałem kiedyś tego rozwiązania (https://www.yunqa.de/delphi/products/sqlite3/index) - podstawową funkcjonalność (niestety, widzę że wersja Personal nie obsługuje 64-bit).

Z pewnością ktoś z Was używa na co dzień SQLite.
Proszę o wskazówki i porady:

1. Implementacja SQLite w Delphi, w sensie dostęp do funkcji i procedur które umożliwiają operacje na danych (odczyt, zapis, etc) + biblioteki SQLite (najlepiej najnowsze) zgodne z implementacją
2. Darmowe i proste w obsłudze
3. Wsparcie dla 64-bit (a jeśli nie, to czy operowanie na bazie 32-bitowej (i dll) w 64 bitowym programie jest problemem?)

Dlaczego o to pytam... świat idzie do przodu, wszystko się zmienia. To co kiedyś używałem (w jednym programie zresztą) jest już przestarzałe. A potrzebne jest rozwiązanie, pewne, proste szybkie i darmowe!

Dzięki,
-Pawel

W pakiecie masz FireDAC (kiedyś to się nazywało AnyDAC )
Albo ZEOS którego trzeba ściągnąć i zainstalować

Pepe napisał(a):

Chciałbym podszkolić swoje umiejętności operowania danymi z bazy danych. Najlepsza dla moich celów jest SQLite

Jest to najgorsza baza do uczenia się jako reprezentant SQL
Niemal nic nie jest tak zgodne z mainstreamem, od typów pól poczynając, przez constraitsy, spsobó pracy jako taki i w ogóle

@Marius.Maximus:
Zaciekawiłeś mnie tym FireDAC. Czy masz pod ręką jakieś dobre przykłady jak tego używać? Takie dla laika... widze w helpie Delphi fragmenty, ale sprzydałoby się jakieś demo zapisu, odczytu danych, sposób tworzenia tabel, usuwania danych - podstawy.

@AnyKtokolwiek: ta baza jest idealna do nauki podstaw, bo jak ktoś zechce zaczynać od Oracle to utknie na instalatorze :D ,

W najprostszej konfiguracji kładziesz na formę TFDConnection -> Ustawiasz mu (dblclick) parametry do Twojego SQLite. Tam masz opcję test connection i w property connection dajesz na TRUE. Następnie dajesz TFDQuery wpisujesz w nim select do tabeli i w connection podpinasz swojego TFDConnection. Następnie dajesz TDataSource podpisznasz w object inspectorze TFDQuery. Rzucasz na formatkę TDBGrid i podpiszasz w object inspector TDataSource. Ustawiasz TFDQuery.Activate = True i sru powinny się na gridzie pojawić.

To jest absolutny początek ale prościej się tego nie da opisać :)

@AnyKtokolwiek: a gdzie zniknął Twój post z propozycja aby uczyć Docker-a ?

Panowie, żadne mi dockery w głowie, ani inne skomplikowane, profesjonalne funkcjonalności.
Nie, jest to żadna fucha, a prywatny projekt - bez żadnego potencjału zarobkowego.

Nie chcę się bawić w jakieś komponenty. W DISQlite (który zalinkowałem) było to rozwiązane bardzo prosto - i być może wrócę do tego rozwiązania (ale myślę, że na rynku może pojawiły się inne rozwiązania). To znaczy, odwołuję się tylko do wrappera, i używam gotowych metod - utwórz bazę, otwórz bazę, dodaj kolumnę, usuń wiersz n, etc... Żadnych cudów.

Przykład z mojego starego kodu (pseudo-kod):

procedure Open_Database;
var
   s8 : UTF8String;
begin
   s8 := Sqlite3_Encode_UTF8(Database_Name);
   Sqlite3_Check(Sqlite3_Open(PUtf8Char(s8), @MOJA_DB), MOJA_DB);
end;

procedure Close_Database;
begin
   Sqlite3_Check(Sqlite3_Close(MOJA_DB), MOJA_DB);
end;

procedure Create_Table;
begin
   try
      Open_Database;
      Sqlite3_Exec_Fast(MOJA_DB, 'CREATE TABLE IF NOT EXISTS IndexT (ID INTEGER PRIMARY KEY, IndexV TEXT);');
	finally
		Close_Database;
	end;
end;

//Odczyt jakiejś wartości
      try
         sqlite3_check(sqlite3_exec(MOJA_DB,
         'SELECT IndexV FROM IndexT;',
         LoadIndex_Callback,
         nil, nil),
         MOJA_DB);
      except
    end;

O takie mniej więcej mi chodzi, bez cudowania :)
-Pawel

Masz tu sampla z Embarcadero:SQLite.zip

woolfik napisał(a):

To jest absolutny początek ale prościej się tego nie da opisać :)

Ale również przepis na to jak NIE pisać programów korzystających z baz danych :)
Jak tak zacznie pisać, to skończy z kodem spaghetti gdzie nie będzie żadnego rozdzielenia pomiędzy logiką, a GUI, a całość będzie zakodowana w zdarzeniach OnClick co tylko spowoduje, że wyrośnie nam kolejny "klikacz Delphi" ;)

Jednak żeby nie było, to można w ten sposób napisać program dający sensowne rozdzielenie GUI od logiki. Jednak nie kładąc komponenty bazodanowe na formatkach.

Co do samego problemu, to warto zainteresować się wyżej wspomnianym Firebird. Ma on wersję embedded która to jest pełnoprawnym serwerem zamkniętym w kilku plikach. Będzie o wiele lepszym wyborem niż SQLite.

Mr.YaHooo napisał(a):

woolfik napisał(a):

To jest absolutny początek ale prościej się tego nie da opisać :)

Ale również przepis na to jak NIE pisać programów korzystających z baz danych :)
Jak tak zacznie pisać, to skończy z kodem spaghetti gdzie nie będzie żadnego rozdzielenia pomiędzy logiką, a GUI, a całość będzie zakodowana w zdarzeniach OnClick co tylko spowoduje, że wyrośnie nam kolejny "klikacz Delphi" ;)

Początki zawsze są trudne ale pokazanie komuś podstaw nie definiuje, że sam się nie rozwinie lub rozwinie się w złym kierunku. Ja zaczynałem od takiego prostego okienkowego GUI pod DB w delphi, a teraz jestem programistą PL/SQL

Jednak żeby nie było, to można w ten sposób napisać program dający sensowne rozdzielenie GUI od logiki. Jednak nie kładąc komponenty bazodanowe na formatkach.

Nie ma kompletnie znaczenia czy rzucisz komponent TFDConnection na klasę bazową TMainForm/TForm dla całej aplikacji czy dorzucisz ją do TDataModule czy też utworzysz ją dynamicznie w runtime (i pozostałe obiekty TFD* też). Fakt trzeba pamiętać o pewnych niuansach ale technicznie nie ma to większego znaczenia. Mówisz natomiast o enakpsulacji i hermetyzacji pewnych ogólnych metodyk programowania, które na moment uczenia mogą spowodować niechęć do programowania w ogóle ... Ja osobiście też nie lubię trzymać logiki tam gdzie GUI tu masz rację natomiast jakby to co wiem teraz po n lat pracy i doświadczenia spadło na mnie na początku to bym został stolarzem bo bym tego nie ogarnął.

Co do samego problemu, to warto zainteresować się wyżej wspomnianym Firebird. Ma on wersję embedded która to jest pełnoprawnym serwerem zamkniętym w kilku plikach. Będzie o wiele lepszym wyborem niż SQLite.

@Pepe: napisał jasno: ponieważ nie będę używał zaawansowanej składni SQL - najprostsze zapytania to myślę, że SQLite mu w zupełności wystarczy

Pamiętaj tylko @Pepe, że SQLite to plik i jako typowy plik nie ma multidostępu czyli jeśli będziesz chciał do tej "bazy" podłączyć się z kilku komputerów to SQLite nie ma takiej funkcjonalności (* tak wiem czytałem, że da się to obejść ale to już jest zupełnie inny temat) i w takiej sytuacji lepiej faktycznie skorzystać z Firebird, o którym pisał @Mr.YaHooo (w firedac zrobisz to dokładnie tak samo)

tak szczerze, to w aplikacjach w których muszę zapamiętać w bazie np. konfigurację lub naprawdę nie dużo danych (czasami nawet trochę więcej) używam często baz ms access. Wrzucam plik bazy do folderu programu i nic więcej nie trzeba robić. Składnia troszkę się różni (zaawansowana) ale jednak da się tego używać.
Poza tym łatwo mi się taką bazę modeluje w dostępnych narzędziach i Windows obsługuję ją natywnie - żadnych ekstra bibliotek.
Inne dobre rozwiązanie to oczywiście MS SQL Server Express i aż ciężko żeby po jakimś czasie używania komputera w sposób trochę inny niż granie w końcu nie trafił na dysk. Tutaj mamy już wszystko, szczególnie gdy doinstalujemy SSMS.
Ale gdyby jednak okazało się że nie ma SQL Serwera na dysku i nie trafi on tam celowo bo to jednak działo na muchę to zawsze można skorzystać z Microsoft SQL Server Compact Edition. Chyba nawet teraz jest on natywnie na dysku.
Jest z tym chyba tylko taki mały problem że w darmowej wersji Delphi nie ma obsługi bazy MS SQL - no ale zawsze zostaje access :).

Mr.YaHooo napisał(a):

woolfik napisał(a):

To jest absolutny początek ale prościej się tego nie da opisać :)

Ale również przepis na to jak NIE pisać programów korzystających z baz danych :)
Jak tak zacznie pisać, to skończy z kodem spaghetti gdzie nie będzie żadnego rozdzielenia pomiędzy logiką, a GUI, a całość będzie zakodowana w zdarzeniach OnClick co tylko spowoduje, że wyrośnie nam kolejny "klikacz Delphi" ;)

Jednak żeby nie było, to można w ten sposób napisać program dający sensowne rozdzielenie GUI od logiki. Jednak nie kładąc komponenty bazodanowe na formatkach.

To po co te komponenty bazodanowe są w Delphi? Po to żeby ich nie używać i nie kłaść na formatkach?

jak ktos chce wyklikac jakies demo w 15 min to moze klikac komponenty - do wszystkiego innego odradzam.

Problem jest taki, że młodych programistow Delphi już nie ma wg mnie, a starzy maja juz swoje wyrobione nawyki, czesto złe i nie ma sensu dyskutować czy onClick czy nie, bo nie dotrze.

do tematu, to sqlite moze i byc, firebird też.

:)
Wbrew tematowi czy typie pytania, nie jest początkującym programistą (jestem amatorem i hobbystą). Ale, zauważcie, że jestem na forum już ponad 20lat... chyba więcej, niż niektórzy z was w zawodzie... i niektóre wpisy mnie nieco ubawiły, choć przyznaję temat raczej dla początkujących... Poruszony problem jest prosty, a zaczynają się porady jak pisać w Delphi, jak jest dobrze, a jak te przebrzydłe dinozaury robią... Amatorski program ma działać, dobrze i niezawodnie - w mojej opinii, to czy "wyklikam" interesujący mnie kod, czy użyję komponentów kładzionych na formę z odpowiednimi powiązaniami, czy też napiszę wszystko "z palca" ma znaczenie drugorzędne - ja tutaj Windows nie pisze :P

Najważniejszy jest wynik - program ma robić to do czego został stworzony i działać w miarę niezawodnie. Podsumowując tę dyskusję, za którą Wam dziękuję - wybiorę chyba implementację DISQLite3, bo tę znam, a nie potrzebuję niczego zaawansowanego. Pakiet Zeos też jest dobrym wyborem (bawiłem się tym kiedyś z MySQL).
Jeszcze tylko napiszę do czego naprawdę to potrzebuję...
Otóż mam wiele plików, w formacie INI (na to teoretycznie nie mam wpływu). Ale każdy z nich może mieć "bardzo" (to subiektywne) dużo sekcji z danymi (np 100 plików, a każdy ma po 10tysięcy wpisów). Program który piszę, ma za zadanie wyświetlić te dane w odpowiedniej formie (coś a'la statystyka). Ale pliki INI nie są dobrym rozwiązaniem dla tak wielu danych. Dlatego mam zamiar wszystkie te pliki scalić w plik bazy danych (utworzyć bazę z jedną tabelą z kolumnami z danymi w odpowiednim formacie) i na niej właśnie operować (tylko odczyt). Dostęp tylko lokalny. Jak widzicie, wiele nie trzeba - wymyśliłem, że taki SQLite będzie akurat.

woolfik napisał(a):

Początki zawsze są trudne ale pokazanie komuś podstaw nie definiuje, że sam się nie rozwinie lub rozwinie się w złym kierunku. Ja zaczynałem od takiego prostego okienkowego GUI pod DB w delphi, a teraz jestem programistą PL/SQL

Oczywiście, ale od razu najlepiej uczyć się dobrych nawyków i eliminować te złe :) Bo czasami bardzo trudno jest wyeliminować złe naleciałości.

woolfik napisał(a):

Nie ma kompletnie znaczenia czy rzucisz komponent TFDConnection na klasę bazową TMainForm/TForm dla całej aplikacji czy dorzucisz ją do TDataModule czy też utworzysz ją dynamicznie w runtime (i pozostałe obiekty TFD* też).

Jak dla mnie wrzucanie komponentów bazodanowych czy połączenia jest niezbyt dobrą praktyką. Odziedziczyłem coś takiego w pracy i lepiej nie mówić jak to jest napisane ;)

woolfik napisał(a):

@Pepe: napisał jasno: ponieważ nie będę używał zaawansowanej składni SQL - najprostsze zapytania to myślę, że SQLite mu w zupełności wystarczy

Oczywiście, kwestia tego czego potrzebuje. Jednak co to zostało napisane już wcześniej, odnośnie niestandardowych rzeczy dla mnie osobiście eliminuje do chyba wszystkich rzeczy.

gajusz800 napisał(a):

To po co te komponenty bazodanowe są w Delphi? Po to żeby ich nie używać i nie kłaść na formatkach?

A czy napisałem, żeby tego nie używać w ogóle? Po prostu nie kładzie się na formatce takich komponentów. Chyba, że chcemy coś sklecić na kolanie albo zrobić jakiś PoC, wtedy jak najbardziej. Jednak jeśli ma to służyć dłużej warto zrobić coś porządnie.

Pepe napisał(a):

Wbrew tematowi czy typie pytania, nie jest początkującym programistą (jestem amatorem i hobbystą). Ale, zauważcie, że jestem na forum już ponad 20lat... chyba więcej, niż niektórzy z was w zawodzie... i niektóre wpisy mnie nieco ubawiły, choć przyznaję temat raczej dla początkujących... Poruszony problem jest prosty, a zaczynają się porady jak pisać w Delphi, jak jest dobrze, a jak te przebrzydłe dinozaury robią... Amatorski program ma działać, dobrze i niezawodnie - w mojej opinii, to czy "wyklikam" interesujący mnie kod, czy użyję komponentów kładzionych na formę z odpowiednimi powiązaniami, czy też napiszę wszystko "z palca" ma znaczenie drugorzędne - ja tutaj Windows nie pisze :P

Oczywiście, że ja to wiem ;) Jednak na temat mogą natrafić również początkujący i czasami warto przypomnieć pewne sprawy :)

Pepe napisał(a):

Otóż mam wiele plików, w formacie INI (na to teoretycznie nie mam wpływu). Ale każdy z nich może mieć "bardzo" (to subiektywne) dużo sekcji z danymi (np 100 plików, a każdy ma po 10tysięcy wpisów). Program który piszę, ma za zadanie wyświetlić te dane w odpowiedniej formie (coś a'la statystyka). Ale pliki INI nie są dobrym rozwiązaniem dla tak wielu danych. Dlatego mam zamiar wszystkie te pliki scalić w plik bazy danych (utworzyć bazę z jedną tabelą z kolumnami z danymi w odpowiednim formacie) i na niej właśnie operować (tylko odczyt). Dostęp tylko lokalny. Jak widzicie, wiele nie trzeba - wymyśliłem, że taki SQLite będzie akurat.

Do takich zastosowań będzie ok. Z takimi danymi poradzi sobie w zasadzie wszystko na czym uruchomi się program.

Pepe napisał(a):

:)
Wbrew tematowi czy typie pytania, nie jest początkującym programistą (jestem amatorem i hobbystą). Ale, zauważcie, że jestem na forum już ponad 20lat... chyba więcej, niż niektórzy z was w zawodzie... i niektóre wpisy mnie nieco ubawiły, choć przyznaję temat raczej dla początkujących...

Ponad 20 letni delfista to w moich oczach ... z pewnością nie Wzorzec Elastyczności Dobrej Architektury w Sevres

lampasss napisał(a):

Problem jest taki, że młodych programistow Delphi już nie ma wg mnie, a starzy maja juz swoje wyrobione nawyki, czesto złe i nie ma sensu dyskutować czy onClick czy nie, bo nie dotrze.

Z ust mi wyjąłeś

U klienta "patronuję" nad niezależnym ode mnie softwarem w Delphi. Jak człowiek (20-30 lat skillu w Delphi) poprawi / doda jedno to popsuje w dwóch miejscach
Widziałem debugowanie, Combo1.OnCLick Buton23.OnClick przez kwadrans, ratunek w zmiennych globalnych
A enduser przechodzi "zasady biznesowe" (np teoretycznie zakazana pozycja zero / null) bo klika w innej kolejności niż autor przewidział

Mr.YaHooo napisał(a):

A czy napisałem, żeby tego nie używać w ogóle? Po prostu nie kładzie się na formatce takich komponentów.

Coś mi tu chyba ściemniasz. Gdyby to było złe, to albo byłoby to zablokowane, albo w dokumentacji byłaby informacja, że to niezalecane. Jest coś o tym w dokumentacji Delphi albo tych komponentów? Bo chyba nie i wygląda na to że powstały z myślą że mają być wrzucane na formę.

Off-topic: A o co wam chodzi z tym językiem Delphi i złymi nawykami programowania?
Delphi przecież opiera się na komponentach, na zdarzeniach. Co jest złego w położeniu dajmy na to przycisku (TButton) na formę (TForm) i obsłudze zdarzenia OnClick? O co chodzi? Przecież na tym to polega, to esencja RAD (Rapid application development).

Rozumiem, że chodzi o to, żeby nie pisać kodu w samej procedurze zdarzenia, tylko oddelegować go do innych modułów poprzez funkcje / procedury, tak? O co cała ta "afera" Delphi? MOże ktoś to porządnie wyjaśnić?

Przepraszam bardzo ale co ma

SQLite

do

nie będę używał zaawansowanej składni SQL - najprostsze zapytania

gajusz800 napisał(a):

Mr.YaHooo napisał(a):

A czy napisałem, żeby tego nie używać w ogóle? Po prostu nie kładzie się na formatce takich komponentów.

Coś mi tu chyba ściemniasz.

Jasne, tylko problem polega na tym, że nie rozumiesz do końca o czym mowa.

Gdyby to było złe, to albo byłoby to zablokowane, albo w dokumentacji byłaby informacja, że to niezalecane.

Poważnie ZALECANE?
No jeśli nawet, to nie na formatkę a na TDataModule
Poza tym, Delphi wg producenta to RAD.
A RAD to zło dla średnich, dużych lub bardziej skomplikowanych projektów niż trywialny CRUD.
Chociaż i w CRUD'olandi to bardziej przeszkadza niż pomaga - nie ma to żadnych, ale to żadnych zalet.

Co nie znaczy, że w Delphi nie można inaczej i koszernie.
A jakże można i tak to się robi, ale to wymaga ciut więcej pomysłu i wiedzy, której w twoim poście nie znajduje.

Jest coś o tym w dokumentacji Delphi albo tych komponentów? Bo chyba nie i wygląda na to że powstały z myślą że mają być wrzucane na formę.

Możesz je wrzucić na dowolny kontener w IDE, co nie znaczy że to jest ZAWSZE świetny pomysł.

Aha no to jeśli dochodzimy do tego, że RAD, czyli to czym Delphi się szczyci to zło to już inna sprawa. Na tym się opiera Delphi i z myślą o RAD zostało stworzone. Więc w ogóle jeśli RAD to całe Delphi to zło. Bo producent w tym produkcie promuje technologię RAD i pod nią rozwija swoje narzędzia.

gajusz800 napisał(a):

Coś mi tu chyba ściemniasz. Gdyby to było złe, to albo byłoby to zablokowane, albo w dokumentacji byłaby informacja, że to niezalecane. Jest coś o tym w dokumentacji Delphi albo tych komponentów? Bo chyba nie i wygląda na to że powstały z myślą że mają być wrzucane na formę.

Od kiedy to jak tak, że jeśli w instrukcji nie napisali, że używanie czegoś w pewien sposób jest złe to jest to dobre? W instrukcji obsługi noża nie napisali, że wepchnięcie go w serce innego człowieka jest złe, jednak każdy wie jak to się skończy....
Delphi to tylko narzędzie, a jak go użyjemy determinuje osoba siedząca przed ekranem komputera. Przecież są artykuły, książki, tutoriale pokazujące jak programować, aby to robić dobrze. Tej wiedzy nie znajdziesz w instrukcji obsługi IDE czy też dokumentacji języka. Większość zasad jest niezależna od języka w jakim się pisze i to nimi należy się kierować podczas pisania kodu. Dobry i słaby kod można napisać w każdym języku. Widziałeś gdzieś w instrukcji IDE wspomniane zasady KISS, YAGNI, czy chociażby potrzebę separacji warstw w programie? No właśnie :)

Pepe napisał(a):

Off-topic: A o co wam chodzi z tym językiem Delphi i złymi nawykami programowania?
Delphi przecież opiera się na komponentach, na zdarzeniach. Co jest złego w położeniu dajmy na to przycisku (TButton) na formę (TForm) i obsłudze zdarzenia OnClick? O co chodzi? Przecież na tym to polega, to esencja RAD (Rapid application development).

Rozumiem, że chodzi o to, żeby nie pisać kodu w samej procedurze zdarzenia, tylko oddelegować go do innych modułów poprzez funkcje / procedury, tak? O co cała ta "afera" Delphi? MOże ktoś to porządnie wyjaśnić?

Mniej więcej o to chodzi. Sam osobiście nie piszę w Delphi, ale C++ Builderze, ale zasada jest podobna. Samo środowisko przecież używa zmiennych globalnych w których siedzą wskaźniki do formatek, data module. Wyklikując sobie powiązania pomiędzy komponentami np. wyżej wspomniane Connection -> Transaction -> Query -> DataSource -> Grid W przypadku gdy wydzielimy komponenty bazodanowe do oddzielnego data module, to wyklikane powiązania wymagają użycia zmiennych globalnych. Po prostu IDE samo podsuwa złe praktyki. Powiedzmy, że przy małych programach da się tak pracować, ale jak stopień skomplikowania i rozmiar systemu rośnie w pewnym momencie zostanie to bez możliwości rozwoju i dodawania nowych funkcji w prosty sposób.

Sam dostałem w pracy spadku program który ma całość zawarte na formatkach. Hitem jest zdarzenie OnActivate dla pewnej formatki. Napiszę tylko, że funkcja ta ma 1 800 linijek kodu Oto do czego prowadzi używanie RAD w większych systemach...

Mr.YaHooo napisał(a):

Delphi to tylko narzędzie, a jak go użyjemy determinuje osoba siedząca przed ekranem komputera.

Skoro tak, to dziwię się, że napisałeś również to:

Hitem jest zdarzenie OnActivate dla pewnej formatki. Napiszę tylko, że funkcja ta ma 1 800 linijek kodu Oto do czego prowadzi używanie RAD w większych systemach...

Oto do czego prowadzi osoba siedząca przed komputerem — nie IDE, nie RAD, nie komponenty, nie rozmiar projektu, a koder. Stosujesz cherry picking. Nie ma wymogu umieszczania pełnej implementacji obsługi zdarzenia w ciele zdarzenia. Można implementację podzielić na mniejsze funkcje (w tym jednorazówki), można je w ogóle wyrzucić do osobnego modułu, a w zdarzeniu jedynie wywołać odpowiednią funkcję.

@Mr.YaHooo: nie do końca chyba rozumiesz o co mi chodzi. Delphi jako takie opiera się na podejściu RAD. Całe środowisko powstało właśnie z myślą o takim użyciu. Więc pisanie, że podejście te jest słabe jest równoznaczne z pisaniem że Delphi jest słabe.

I nie bardzo rozumiem czemu RAD miałoby wykluczać dobre praktyki. Czemu komponenty na formularzu (a po to zostały stworzone) mają oznaczać coś złego.

furious programming napisał(a):

Nie ma wymogu umieszczania pełnej implementacji obsługi zdarzenia w ciele zdarzenia. Można implementację podzielić na mniejsze funkcje (w tym jednorazówki), można je w ogóle wyrzucić do osobnego modułu, a w zdarzeniu jedynie wywołać odpowiednią funkcję.

Owszem, nie ma takiego wymogu. Nie mniej jednak wielu początkujących programistów Delphi/C++ Builder'a stosuje upychanie całości na formatkach. Przypadek, a może po prostu schemat działania narzędzi typu RAD zachęca do takiego pisania programów?

gajusz800 napisał(a):

I nie bardzo rozumiem czemu RAD miałoby wykluczać dobre praktyki. Czemu komponenty na formularzu (a po to zostały stworzone) mają oznaczać coś złego.

Wykluczać to na pewno nie. Bo za pomocą RAD'ów można ładnie pisać, ale wymaga to zaplanowania i napisania większej ilości kodu. A czemu kładzenie komponentów bazodanowych na formatkach jest złe? Miesza się odpowiedzialności. Masz w jednej klasie prezentację danych oraz ich pobieranie z bazy. To dobre podejście? Kolejną sprawą, że IDE domyślnie korzysta ze zmiennych globalnych, a te już same z siebie to zło, bo chociażby wprowadza niejawne zależności pomiędzy modułami.

Mr.YaHooo napisał(a):

Nie mniej jednak wielu początkujących programistów Delphi/C++ Builder'a stosuje upychanie całości na formatkach.

Nigdy nie oceniaj jakości technologii na podstawie losowego, gównianego kodu, napisanego przez kogoś, kto nie potrafi pisać dobrego kodu. Nigdy i żadnej technologii, bo to nie technologia winna, że jej użytkownik jest dzbanem. ;)

Przypadek, a może po prostu schemat działania narzędzi typu RAD zachęca do takiego pisania programów?

System komponentów wizualnych w Delphi, Lazarusie i innych narzędziach RAD jest tak zbudowany, aby kod obsługi tych komponentów był implementowany w zdarzeniach, których ciała generowane są automatycznie przez IDE. Jeśli chcesz oprogramować interakcję z kontrolką, uzupełniasz konkretne zdarzenie i koniec. Nieistotne jest to na ile metod podzielisz kod zdarzenia, ani czy skorzystasz z tego wygenerowanego czy podłączysz swoje z zewnątrz w runtime — całość sprowadza się do przewidzianego przez producenta zdarzenia kontrolki.

I tak samo jest np. w Unity — silnik zaprogramowany jest tak a nie inaczej, więc jego użytkownik korzysta z tego, co przygotowali jego twórcy (czyli konkretne klasy i metody). Nieistotne jest to, czy cały kod napiszesz w danej metodzie, czy podzielisz go na wiele metod, tak czy siak ta konkretna metoda silnika musi być wywołana. Możesz napisać w niej 1800 linii kodu, a możesz tylko jedną — z wywołaniem właściwej metody, zaimplementowanej gdzieś indziej.

Tak więc to nie jest kwestia zachęcania czy nie, a architektury danej technologii. Natomiast zadaniem użytkownika jest dostosowanie się do specyfiki architektury i napisanie takiego kodu, aby dało się go wygodnie utrzymywać.

furious programming napisał(a):

Nigdy nie oceniaj jakości technologii na podstawie losowego, gównianego kodu, napisanego przez kogoś, kto nie potrafi pisać dobrego kodu. Nigdy i żadnej technologii, bo to nie technologia winna, że jej użytkownik jest dzbanem. ;)

Racja, nie powinno się tak oceniać. Analogicznie jak nie broń zabija, a człowiek który ją trzyma w ręku i ciągnie za spust ;)

furious programming napisał(a):

System komponentów wizualnych w Delphi, Lazarusie i innych narzędziach RAD jest tak zbudowany, aby kod obsługi tych komponentów był implementowany w zdarzeniach, których ciała generowane są automatycznie przez IDE. Jeśli chcesz oprogramować interakcję z kontrolką, uzupełniasz konkretne zdarzenie i koniec. Nieistotne jest to na ile metod podzielisz kod zdarzenia, ani czy skorzystasz z tego wygenerowanego czy podłączysz swoje z zewnątrz w runtime — całość sprowadza się do przewidzianego przez producenta zdarzenia kontrolki.

To jest akurat dobre podejście. Jednak trochę rozleniwia. Skoro mam wygenerowane zdarzenie, to wszystko ląduje wewnątrz jego. Niestety dużo ludzi tak myśli i tak właśnie robi. Tylko co z tymi nieszczęsnymi zmiennymi globalnymi które IDE tworzy podczas tworzenia nowego formularza? Przecież wiadomo, że należy ich unikać. Więc po co w ogóle je tworzyć z automatu?

furious programming napisał(a):

Tak więc to nie jest kwestia zachęcania czy nie, a architektury danej technologii. Natomiast zadaniem użytkownika jest dostosowanie się do specyfiki architektury i napisanie takiego kodu, aby dało się go wygodnie utrzymywać.

Tak, a zadaniem autorów danej technologii jest dobre zaprojektowanie frameworka, aby wygodnie się z niego korzystało.

Mr.YaHooo napisał(a):

Tak, a zadaniem autorów danej technologii jest dobre zaprojektowanie frameworka, aby wygodnie się z niego korzystało.

I dlatego właśnie komponenty mają zdarzenia, bo są bardzo wygodne. :]

@Mr.YaHooo:

Tylko co z tymi nieszczęsnymi zmiennymi globalnymi które IDE tworzy podczas tworzenia nowego formularza? Przecież wiadomo, że należy ich unikać. Więc po co w ogóle je tworzyć z automatu?

Automat IDE działa tak jak działa.
Jeśli już mam potrzebę (albo chęć :) ) aby utworzyć formularz w IDE to w pierwszym kroku po utworzeniu nowej formy wywalam tę zmienną globalną