Visual Studio vs Delphi do baz danych – porównanie gigantów

Kiedyś zamieściłem wpis na temat wyboru języka oraz środowiska pracy dewelopera. Nadmieniam, że nie porównywałem wówczas języka, lecz środowiska programistycznego – jako całości. Zrobiłem to celowo, bowiem w mojej opinii walki toczące się w sieci na temat wyższości jednego środowiska nad innym, choć słabnące, wciąż się pojawiają. W tym wpisie postaram się wyjaśnić kilka wątpliwości, porównując oba środowiska pod kątem pisania aplikacji bazodanowych, bo takimi systemami się właśnie zajmuję. Wpis dotyczy aplikacji typu desktop, które wziąć rozwijam, ale jest też kilka drobnych wzmianek o aplikacjach webowych – celem porównania. Nadmieniam, że jest to wpis subiektywny, poparty moim doświadczeniem w Delphi i PHP i o wiele mniejszym doświadczeniem w Visual Studio, do którego wciąż staram się przekonać.



Chyba każdy programista chce pracować w środowisku programistycznym, które oferuje kompletne narzędzia do budowy aplikacji. Od wygodnego kreatora formularzy, wsparcia w generowaniu zapytań SQL czy systemu raportów. Ja też mam swoje wymagania, które sprawiłyby, że środowisko, którego używam, nazwałbym idealnym. Jednakże nigdy dotąd takiego nie spotkałem. Napiszę teraz w punktach i uzasadnię, jak w mojej opinii powinno wyglądać idealne środowisko programistyczne, za pomocą którego w prosty i czytelny sposób tworzyło by się soft oparty o bazy danych.

Jak więc powinno wyglądać środowisko idealne i jak się to ma do Delphi i Visual Studio?

porównanie: Delphi w wersji Delphi 2006 professional oraz Visual Studio 2017 Community.

Dołączone biblioteki do łączenia się z co najmniej serwerami: MS SQL, mySql, pSQL, Oracle, SQLite.

W tym punkcie mam na myśli zestaw gotowych bibliotek, za pomocą których nie trzeba „grzebać” w sieci w poszukiwaniu odpowiednich i zgodnych bibliotek, bowiem są one dostępne po zainstalowaniu środowiska programistycznego i od razu gotowe do użycia.

Na tym polu bezwzględnie wygrywa Embarcadero Delphi. Wbudowane w to środowisko komponenty umożliwiają łączenie się z popularnymi bazami danych. A jeśli czegoś brakuje, można dokupić Universal Data Access Components od DevArt. Wówczas lista bibliotek do łączenia z różnymi bazami jest imponująca:

Co więcej – zarówno wbudowane komponenty Delphi, jak i dodatkowe komponenty UniDac, oferują łączenie się z serwerami oraz korzystanie z danych z wyjątkową łatwością, nieznaną w Visual Studio, w którym gdy chcesz skorzystać z innych baz niż SQL Server, również możesz pobrać odpowiednie biblioteki za pomocą managera NU Get, ale potem musisz być silny, walczyć i pogodzić się, że wiele nawet podstawowych kwestii, nawet takich jak połączenie, musisz zrealizować ręcznie – w kodzie.

Umożliwia wizualne tworzenie zapytań/widoków.

Tworząc oprogramowanie wykorzystujące bazy danych, często zachodzi potrzeba utworzenia bardziej skomplikowanego zapytania do bazy czy optymalizacji istniejących zapytań. Nie każdy programista jest jednak specjalistą od SQL, stąd zajdzie taka potrzeba, lub gdy trzeba utworzyć np. widok lub select składający się z wielu tabel i warunków, zaczyna się problem. Jeśli wykorzystuję SQL, wykorzystuję do tego zewnętrzne narzędzia, jak SQL Management, czy DevArt MySQL Query Builder. Fajnie by jednak było, gdyby takie narzędzia były wbudowane w interfejs środowiska programistycznego. Tymczasem w obu środowiskach znaleźć można jedynie uproszczony podgląd danych i prosty edytor kwerend. Reasumując – Visual Studio i Delphi oferuje nam tego typu narzędzia, ale odczuwam pewien niedosyt podczas korzystania z tych wbudowanych funkcji.



Posiada wbudowany ORM, lecz umożliwia również wykonywanie natywnych zapytań SQL.

W zależności od stopnia złożoności pisanej aplikacji, może zajść potrzeba sięgnięcia po bardziej wyrafinowane narzędzia do przetwarzania danych. Wszak gdy założymy, że tworzony system może w przyszłości wykorzystywać różne rodzaje serwerów baz danych, niebezpieczne jest zaszywanie w kodzie SQL, który różni się w zależności od wybranego serwera.

Delphi posiada proste metody manipulacji danymi w tabelach danych. I czyni to automatycznie – kontrolki dedykowane do interakcji z bazami danych same wiedzą, jak zapisać edytowane dane. W prostszych przypadkach można więc napisać prost aplikację bazodanową nie pisząc ani jednej linii kodu. A im miej kodu, tym mniej błędów. A jeśli zachodzi potrzeba”ręcznej” edycji rekordu, robi się to banalnie. Np. Mamy tabelę adresy z polami imie, nazwisko, wiek, w które musimy dokonać zmiany w kodu aktualnego rekordu w DBGridzie, wystarczy napisać:

Adresy.Edit;
Adresy.FieldByName('imie').AsString := 'Janusz';
Adresy.FieldByName('nazwisko').AsString := 'Kowalski';
Adresy.FieldByName('wiek,').AsInteger := 32;
Adresy.Post;

Prawda że proste? Bez pisania SQL, bez zabawy w DataSety, DataRowy czy SQLa. Visual Studio domyślnie nie oferuje na tym polu nic fajnego i trzeba się opisać, aby uzyskać podobny efekt. Mimo wszystko brakuje mi tu protych funkcji znanych z ORMów PHP, jak np. All, FindBy, Get, contain, conditions, etc. Oczywiście można to uzyskać, jest możliwość filtrowania, ale to za mało. Zawsze też można też skorzystać z TQuery.

Visual Studio jest jest bardziej elastyczne. Można skorzystać zarówno z SQL, DataSet lub użyć czegoś potężniejszego, czyli Entity Framework. jest to ORM, którego przez jakiś czas testowałem. Już na początku testów zauważyłem, że niewiele tu robi się i dzieje wizualnie. Visual Studio to klepanie kodu – mnóstwa kodu. Testowałem EF pod kątem wykorzystania w aplikacjach typu desktop (Windows Forms oraz WPF) i nie do końca chyba rozumiem filozofię tego narzędzia. Założenia są jak najbardziej poprawne – EF sprawia wrażenie przyjemnego w użytkowaniu, co potwierdza wiele filmów na YouTube, pod niebiosa wychwalające możliwości tego narzędzia. Dlatego też postanowiłem przetestować je osobiście. Niestety, nie mam najlepszego zdania o tym wynalazku. Otóż człowiek przyzwyczajony do Delphi, gdzie bo po prostu wszystko działa, zderza się z przykrą rzeczywistością i zauważa generowany przez środowisko EF burdel. Dziwne, bo sama składnia zapytań EF jest bardzo przyjemna, można znaleźć na ten temat sporo dokumentacji i bardzo łatwo modyfikować rekordy, wstawiać dowolne warunki czy łączyć źródła danych do kontrolek.

Tyle tylko, że wszystko odbywa się programowo, czyli nie ma mowy o podglądzie na żywo, które tak lubię. Dodatkowo naprawdę ciężko (w porównaniu z Delphi) używać np. ComboBox (jako DropDownList), czy innych kontrolek. Ileż trzeba się opisać, żeby osiągnąć to samo co w można osiągnąć w ciągu kilku minut w Delphi? EF ma bardzo fajnie rozwiązane relacje, które tworzą się już na etapie automatycznego tworzenia modeli z bazy i są w łatwy sposób dostępne z kodu.

Niektóre funkcje EF jednak zasługują na pochwałę. Np. proszę zobaczyć, jak łatwo można pobrać z bazy zlecenia przy spełnieniu dwóch warunków przy pomocy Entity Framework.

bazaEntities dane = new bazaEntities();
var zlecenia = dane.zlecenia.FirstOrDefault(f=>f.aktywne==true && f.brutto>1000);

czy jak łatwo wprowadzić wyszukiwanie w DataGridView wpisując coś w txtSzukaj – wszystko działa błyskawicznie:

 private void txtSzukaj_KeyPress(object sender, KeyPressEventArgs e)
  {
    if (txtSzukaj.Text.Trim().Length < 1)
     {
      gridNaprawyAuta.DataSource = vnaprawy.repairs_devices.ToList();
     }
     else
     {
    gridNaprawyAuta.DataSource = (from naprawy_auta in vnaprawy.repairs_devices where
    naprawy_auta.device_rejestracja.Contains(txtSzukaj.Text.Trim())
   || naprawy_auta.device_vin.Contains(txtSzukaj.Text.Trim())
   || naprawy_auta.device_name.Contains(txtSzukaj.Text.Trim())
   || naprawy_auta.device_manufacturer.Contains(txtSzukaj.Text.Trim())
   || naprawy_auta.device_engine.Contains(txtSzukaj.Text.Trim())
   select naprawy_auta).ToList();
 }
  disable_filter();
 }

Teoretycznie EF jest wymarzonym narzędziem, który sprawia, że rzadziej sięgamy po SQLa. Mam jednak poważne zastrzeżenia co do jego stabilności. Mało jest też informacji na temat jego wad i niedociągnięć. Skąd więc ten sukces EF? Być może tkwi on w polityce Microsoft, które produkuje filmy i reklamy, na których fanatycy bez mrugnięcia okiem wychwalają EF jako najlepsze i jedyne rozsądne rozwiązanie?

Co jest nie tak z Entity Framework? Początek pracy w EF wydaje się prosty i logiczny. Należy go pobrać do projektu z menadżera pakietów. Potem trzeba utworzyć połączenie z bazą. Następnie wygenerować modele (ADO Entity Data Model) i na koniec utworzyć źródła danych. I właśnie tutaj zaczynają się schody. Visual Studio ma problemy nawet z własnym serwerem SQL. Ten opis dotyczy trybu database first, bo tym się akurat zajmowałem, ponieważ mam sporo napisanych systemów, gdzie bazy są już gotowe i przetestowane. Tymczasem EF niepoprawnie generuje modele i trzeba ręcznie przerabiać źródła. W przeciwnym wypadku nie da się dodać nic do DataSeta. Ale co dziwne – zdarza się, że funkcja ta działa zupełnie poprawnie! Nie wiem o co chodzi, może ktoś z Państwa mi to wytłumaczy? Wiem, że pomaga zmienić kilka linii w modelu .tt i zadziała. Tyle tylko, że moje Visual Studio 2017 (Windows Forms) raz działa, a raz nie i zmiana pliku .tt nic nie daje.

A jak już zadziała, to nie na długo, bowiem Entity Framework potrafi wykrzaczyć się przy aktualizacji bazy z modelu i odwrotnie, zaś moja aplikacja po prostu przestaje działać i sypie mnóstwem błędów. Ilość samoistnie występujących problemów rośnie wraz z rozbudową aplikacji. Być może w trybie code first tych problemów nie ma, ale ja potrzebuję database first i model first. Może tutaj są jakieś „haczyki”, których nie potrafię ogarnąć? Myślę, że tak, bo w przeciwnym wypadku EF to jakaś totalna pomyłka. Dlatego właśnie mam dość tego ORMa już po tygodniu testów. Przez ten czas moim głównym zadaniem było poprawianie błędów, aby w ogóle uruchomić aplikację. Co ma takiego EF, czego nie miałbym w Delphi? A może ktoś z czytających wyjaśni jak to cholerstwo skonfigurować, by działało? Jak w prosty sposób bindować kontrolki, żeby się nie rozwalało przy zmianie modelu? Interesuje mnie wyłącznie Windows Forms oraz WPF.



Inna sprawą jest to, że EF to prawdziwa kobyła, która może i jest dobra do pisania systemów ASP.NET klasy enterprise, ale pisanie w tym prostej aplikacji (moja aplikacja testowa miała kilkanaście tabel), więc użycie do tego EF to jak strzelanie z działa do mrówki. Potrzebuję czegoś prostszego. Na szczęście do Visual Studio jest kilka dobrych ORMów, z których testowałem np. Dappera. Ale co z tego, jeśli nie ma on możliwości wygenerowania klas z istniejącej bazy i trzeba to wszystko pisać ręcznie? Najbardziej spodobał mi się Simple.Data, ponieważ choć testy szybkości nie powalały, ma on bardzo proste metody dostępu. Tyle tylko, że nie jest już rozwijany. A szkoda, bo jego składnia bardzo przypomina ActiveRecord z PHP. Niestety nie przetestowałem NHibernate – czy ktoś tego używa i czy jest lepsze od EF? Visual Studio ma naprawdę sporo dostępnych bibliotek tego typu i jeśli ktoś z was ma czas, może sobie poszukać odpowiedniego. Problemem będzie tylko database first i generowanie modeli z bazy, ale widziałem płatne narzędzia do generowania klas na podstawie bazy – takie reverse enginering, albo pozostaje klepanie kodu – i to jakaś cholerna norma w Visual Studio.

Posiada wbudowany system pomocy – znany w Visual Studio pod nazwą IntelliSense.

Nie ukrywam, że kombajn Visual Studio sprawia się na tym polu znakomicie. Intelli Sense jest genialne i potrafi rozwiązań wiele błędów podczas programowania. Delphi nie jest pod tym kątem tak dobre. Trzeba spróbować obu narzędzi, aby wiedzieć, o czym piszę. Intelli Sense jest najlepsze i koniec! Visual Studio postawiło na prostotę interfejsu i wygodę. Co prawda żeby Visual Studio działało w miarę płynnie, trzeba było mieć 20-rdzeniową maszynę z 20GB RAM, ale to się zmieniło. Odczułem, że VS2017 działa szybciej nawet na moim starym Dellu 3GHZ i 8GB RAM. Delphi działa dobrze nawet na starym, wysłużonym laptopie i należy podkreślić, że działa bez zacięć znanych z VS. Może wynika to z tego, że VS jest pisany w NET. Framerowk, w którym, jak mówią fachowcy – kod pośredni jest tak dobrze zoptymalizowany, że nie ustępuje natywnym aplikacjom EXE?

Musi umożliwiać szybkie tworzenie interfejsów użytkownika poprzez układanie komponentów na formatce.

Zarówno Delphi, jak i Visual Studio oferują narzędzie do tworzenia formatek za pomocą mechanizmu przenieś i upuść i oba narzędzia posiadają domyślnie tak samo marne komponenty, czego koronnym przykładem jest wbudowany DBGrid w Delphi i DataGridView w Visual Studio. Obydwa gridy to po prostu porażka i wymagają wielogodzinnego ślęczenia nad ich skonfigurowaniem, żeby uzyskać jaki taki wygląd oraz funkcjonalność. I niestety w obu przypadkach trzeba naklepać kodu. Dlatego też do poważniejszych zastosowań należy posiłkować się komponentami firm trzecich, a to już sporo kosztuje. Prawdziwe programowanie należy więc zacząć od zrobienia zakupów, albo tracić czas na tworzenie własnych kontrolek, co jest w mojej opinii bez sensu. Jeśli chodzi o technologie tworzenia interfejsów użytkownika, Visual Studio  ma sporą zaletę – choć w mojej opinii nieco wątpliwą. Otóż mamy tutaj większy wybór technologii: Windows Forms, WPF, albo UWP. Testowałem Windows Forms i jest to zbliżone do Delphi. Jeśli zaś chodzi o WPF, to mamy tutaj o wiele więcej możliwości: UI może być ładniejsze i bardzo mi się podoba. Ma też być szybsze, tyle tylko, że jakoś tego nie zauważyłem. Poza tum nie mam czasu na zabawę z XAMLem. W Delphi czy Windows Forms formatkę tworzy się błyskawicznie – jest to przecież środowisko RAD a nie zabawa w XAMLu. Interfejsy pisało się ręcznie w DOSie – w Cliperze lub dBase ale współcześnie? Odnoszę wrażenie, że Microsoft zrobił na tym polu raczej krok w tył, stawiając na XAMLa, zamiast udostępnić wygodną i pełną listę właściwości w oknie właściwości. Uważam także  pewnie wbrew zachwalającym, że XAML jest mało wygodny choćby dlatego, że niewiele na ekranie widać. Być może, jak ktoś ma 50 calowy monitor lub dwa monitory developerskie, to co innego, ale jak do cholery na 15′ laptopie wyświetlić te wszystkie okna i jeszcze widzieć formę, którą się akurat projektuje? Mam ją zmniejszyć do 15%?

Podczas projektowania interfejsu, musi umożliwiać podgląd danych na żywo.

Programiści Delphi wiedzą o co chodzi. Programiści Visual Studio – nie do końca. Otóż podczas budowania bardziej skomplikowanych formularzy przydaje się podgląd danych na żywo, co umożliwia lepsze i szybsze projektowanie. W Delphi, używając dowolnych kontrolek bazodanowych, możemy połączyć się w trybie projektowania i „na żywo”, czyli podczas trybu projektowania, widzieć dane z bazy danych w TextBoxach, ComboBoxach czy w DBGridach. Naprawdę to bardzo pomaga – szczególnie w przypadku wielu relacji na jednej formatce. Tymczasem w Visual Studio trudno doszukać się takiej opcji jest co prawda podgląd kolumn, ale danych już nie ma. W przypadku korzystania z ORM nic nie ma. A może czegoś nie wiem?

Powinien mieć możliwość dowolnego bindowania kontrolek zarówno między sobą, jak i z danymi w bazie.

Tutaj zdecydowanie wygrywa Visual Studio, w którym bindować można niemal każdą kontrolkę. Np. TextBox może zostać zbindowany do pola w tabeli bazy danych. W Delphi jest nieco inaczej – musi być do tego użyty komponent DBTextBox, bowiem „zwykły” TextBox tego nie potrafi. Niby głupota, ale to w Delphi przeszkadza, np. gdy przy zmianie koncepcji zachodzi konieczność podmiany komponentów oraz metod przypiętych do zdarzeń, gdy komponent takie posiada.

Musi posiadać wbudowaną walidację kontrolek oraz obsługiwać błędy użytkownika bez pisania kodu.

W obu przypadkach jest totalne dziadostwo. Zarówno Delphi, jak i Visual Studio nie mają domyślnych kontrolek, którym można nadać np. takie właściwości: wpuszczaj tylko typ currency i dodawaj lokalną walutę. Jeśli niewypełnione, wyświetl błąd i nie pozwól przejść dalej. Dziwne, bo np. chyba w każdym frameworku PHP jest to wbudowane. W przypadku Delphi, gdy DBTextBox jest zbindowany z polem ADOTable, to jeśli to pole ma konkretny typ, jest to pewne zabezpieczenie, ale dalekie od tego, czego bym chciał. Istnieją jednak komponenty, które to potrafią, tylko czy była to trudność dla producenta, by wyposażył standardowe kontrolki w tego typu – podstawową wg mnie funkcjonalność?

Musi zawierać prosty i uniwersalny  język programowania.

Wiem, trudno jest zdefiniować jak ma wyglądać ideał języka programowania, jednak w mojej opinii c# jest zbliżony do ideału. A teraz cytat z Nonsensopedii, który bardzo przypadł mi do gustu: C# to język, który według Microsoftu jest najlepszy (pomimo tego, żadne oficjalne aplikacje Microsoftu w nim nie powstają). Ukradł wszystko co można z języka Delphi (wsparcie dla programowania zorientowanego komponentowo) oraz języka Java (platforma .NET jako alternatywa dla platformy JAVA, składnia C++ bez wskaźników). Oczywiście M$ nie mówi, że czerpał inspiracje dla rozwiązań C# z języka Delphi, tylko z archaicznego języka Smalltalk (którego nikt normalny nigdy nie widział). Powodem tego jest fakt, że główny architekt Delphi został przekupiony przez Microsoft i zabrany z teamu tworzącego kompilator Delphi do firmy Microsoft.



Jeśli zaś chodzi o wyższość języka C# nad Object Pascalem, to argumenty, które pojawiają się na tym polu, są delikatnie mówiąc – śmieszne. Nie ma czegoś takiego jak wyższość jednego języka nad innym. Liczy się jedynie produktywność, co w mojej opinii oznacza składową: siły bibliotek, prostej składni języka – czyli jak najmniejszej ilości pułapek, co w konsekwencji służyć ma szybszemu rozwiązaniu konkretnego problemu. Nie lubię dorabiania do tego niepotrzebnej ideologii. Proszę zauważyć, że podobne kłótnie toczą się nad tym, czy lepszy do tworzenia aplikacji web jest C# i ASP.NET czy „dziadowski” PHP. Biorąc pod uwagę moje subiektywne wymagania, ale i światowe trendy, zdecydowanie wygrywa PHP + framework, lub jeśli ktoś jest naprawdę dobry, „czysty” PHP. Bowiem jedynie prawdziwi fachowcy umieją napisać dowolnie skomplikowaną, szybką i bezpieczną aplikację w PHP bez użycia frameworka. Czy jest inaczej? Tymczasem gdy czytam niektóre porady o tym, że C# jest lepszy, bo nowocześniejszy i tylko dinozaury piszą w PHP czy Pascalu, robi mi się słabo. Bo to cholernie słabe argumenty, które świadczą jedynie o niewiedzy piszącego takowe porady i niepotrzebnie szukającego filozofii w zwykłym narzędziu. Co to znaczy, że C# i ASP.NET jest coraz popularniejszy? Przecież 82% stron na świecie oparte jest na technologii PHP. Jak masz dobrego frameworka, aplikację w PHP napiszesz w dzień i odpalisz w 5 minut na najtańszym hostingu. Spróbuj tego samego z ASP.NET… Podobnie przy porównaniu Delphi i C# – aplikację w Delphi napiszesz w pół godziny, gdzie C# pół godziny zajmuje pobieranie bibliotek, konfiguracja połączeń i walka z ORMem. A wiecie ile aplikacji powstało w Delphi? Kiedyś pisało się niemal wyłącznie w tym środowisku, co zaowocowało wysypem aplikacji pisanych właśnie w Delphi. Można wręcz powiedzieć, że C# dopiero raczkuje, zdobywając rynek. Fakt – popularność rośnie bardzo dynamicznie, ale to samo było w przypadku pojawienia się Delphi. To był przełom, ale dziś jaki to przełom? Nie zapominajmy, że wiele systemów np. finansowych jest napisanych w środowiskach takich jak Power Builder, Clarion, które są stricte przeznaczone do systemów biznesowych. I choć są to systemy stare, to na pewno nie są przestarzałe i jakoś się trzymają. Może tylko zmieniają właścicieli, ale wciąż są. Języki takie jak C++ czy C są również bardzo stare, ale czy to oznacza, że używają ich tylko dinozaury i są do niczego? Dlatego powiedzenie, że Pascal jest przestarzały i że Delphi to zła technologia ze względu na małą popularność jest zupełnie pozbawiona sensu. W rzeczywistości jest inaczej – Delphi wciąż jest używane. Ponieważ język, to tylko narzędzie, zaś środowisko programistyczne, to warsztat pracy. I to wszystko w tym temacie.

Posiada wbudowany kreator wersji instalacyjnej oraz umożliwiać aktualizację aplikacji.

Na tym polu wygrywa Visual Studio, w którym mogę utworzyć paczkę instalacyjną wraz z zależnościami, od których zależy działanie mojego programu. Owe zależności mogę dodać do instalki, lub spowodować, że instalator u klienta pobierze wymagane paczki z sieci. Z drugiej strony Delphi nie wymaga żadnych zależności, więc jest to zupełnie niepotrzebne. Dla Delphi można użyć np. Inno Setup i instalka gotowa. Jednakże Visual Studio oferuje nie tylko automatyczne generowanie wersji instalacyjnej, ale również umożliwia publikowanie instalki na serwerze ftp, zaś zainstalowana aplikacja u klienta podczas uruchamiania może sprawdzać dostępność nowych wersji i w razie konieczności – pobrać ją i automatycznie zainstalować. To zdecydowanie pomaga w utrzymaniu aplikacji i zmniejsza ilość telefonów od klientów.

Dlaczego uważam, że Delphi jest lepsze do projektowania aplikacji bazodanowych?

  1. Ponieważ umożliwia szybkie prototypowanie aplikacji (GUI+połączenie i interakcja z bazą) i klient może w ciągu kilku dni otrzymać realnie działającą aplikację i ocenić stan prac.
  2. Ponieważ nie musisz męczyć się ze stosem konfiguracji, zanim w ogóle uda się połączyć z bazą danych, chyba że w VS użyjesz jedynie słusznej bazy MS SQL Server.
  3. Masz podgląd na żywo podczas projektowania aplikacji i pracujesz na „żywych” danych, co niezwykle pomaga w tworzeniu wyglądu formularzy aplikacji. W DBGrid lub gridach innych firm widzisz na żywo kolumny oraz dane, co pozwala błyskawicznie skonfigurować właściwości i rozmiar kolumn.
  4. Prosty dostęp do danych z kodu umożliwia połączenie tworzenia za pomocą techniki przeciągnij i upuść oraz jednocześnie interakcję z danymi za pomocą kodu.
  5. Ponieważ Delphi generuje natywny kod – programy uruchamiają się i działają szybciej – i nie daj się zwieźć, że „nowoczesne pliki pośrednie są teraz zoptymalizowane i działają tak szybko jak binarki”.
  6. Ponieważ za pomocą Delphi napiszesz program wykorzystujący niemal każdy serwer baz danych czy bazę plikową.
  7. Ponieważ jest mnóstwo darmowych oraz tanich komponentów, które możesz zainstalować i po prostu wykorzystać we własnych aplikacjach.
  8. Ponieważ w Delphi nie istnieje problem znany mi z C# i w oknach potomnych dowolna formatka może w prosty sposób korzystać z DataSource z innej formatki. Można więc wyświetlić dialog edycji rekordu i zawsze wiesz, że w nowym oknie (dialogu) będzie edytowany właściwy rekord i to bez ręcznego przypisywania wszystkich danych rekordu do pól textBox w oknie potomnym i odwrotnie.
  9. Kontrolki bazodanowe w Delphi umożliwiają ustalanie relacji między nimi, a dzięki temu, realizacja dowolnych relacji pomiędzy tabelami jest prosta i przyjemna. Nic się też nie rozwali, jeśli zmienisz coś w bazie, najwyżej wyświetli błąd, który poprawisz nie dotykając kodu.

A teraz krótki film ukazujący filozofię Delphi – prosty program bazodanowy w 2 minuty. prozę mi wierzyć – rozbudowa o master detail czy edycję danych w oknie dialog to kolejne 2 minuty. Jest to bardo stara wersja Delphi, nowe wyglądają lepiej i pozwalają na więcej.

Delphi to idealne środowisko do tworzenia aplikacji biznesowych, pozwalając w sposób niezwykle efektywny na tworzenie programów okienkowych za pomocą dziadowskiego, ale niezwykle prostego języka Object Pascal. Delphi to środowisko, które pozwana na zbudowanie w ciągu jednego dnia porządnej aplikacji bazodanowej, jednak ustępuje pola nowoczesnemu Visual Studio, w którym to samo zrobisz w tydzień, ale za to w sposób nowoczesny. Zaletą wyboru Visual Studio może nie będzie szybkość dostarczenia gotowego produktu, ale na pewno będziesz bardziej trendy.

A teraz podsumowanie – zupełnie na serio.

Visual Studio

Gdyby dodać do Visual Studio prostotę projektowania aplikacji bazodanowych znanej z Delphi, byłoby to środowisko idealne. Gdyby Visual Studio było wizualne nie tylko z nazwy, byłby to całkiem dobry produkt. Gdyby wbudowane kontrolki były odrobinę lepsze a dataGridView oferował więcej, niż obecnie, to już byłoby coś. Największą zaletą jest darmowość tego narzędzia, co przekłada się na jego powszechność.

Delphi

Gdyby cena Delphi professional wynosiła maksymalnie 3000 zł., być może środowisko to byłoby znów na topie. Ale przy obecnej cenie i braku darmowego dostępu do narzędzi dla uczelni, mamy klapę. Na szczęście Embarcadero się budzi i ma nowy program akademicki, dzięki któremu będzie wyposażać pracownie szkół średnich i uczelni wyższych w darmowe licencje Delphi i C++ Builder. Lepiej późno, niż wcale. Gdyby jeszcze poważnie podeszli do freelancerów i oferowali poważniejsze zniżki, byłoby to dobre posunięcie ze strony firmy.

Lazarus i CodeTyphon

Najzabawniejsze jest to, że środowisko programistyczne Lazarus, oferuje wiele możliwości, które oferują w podstawowe wersje Delphi i Visual Studio. Posiada system raportowania, kontrolki bazodanowe, edytor GUI i edytor kodu. Tyle tylko, że ma kilka wad, jak na przykład przestarzałe IDE oraz największą wadę – dodanie nowej kontrolki oznacza konieczność przekompilowania całego środowiska. A to ze względu na durną licencję. CodeTyphon zaś, to Lazarus, tyle tylko, że z normalniejszym interfejsem oraz dołączoną ogromną kolekcją kontrolek.

Reasumując, pisząc proste aplikacje, w których stosuję do kilkadzięciu tabel, więc wolę nie być nowoczesny, tylko tworzyć aplikacje bazodanowe w starym, ale dobrym Delphi, darmowym Lazarusie lub CodeTyphon. Dlatego też, jeżeli jeszcze nie spróbowaliście, serdecznie polecam Państwu zainstalowanie Lazarusa lub CodeTyphon i porównanie ich możliwości z produktami komercyjnymi przy pisaniu systemów bazodanowych. Choćby po to, by dojrzeć różnicę i mieć pojęcie o tym, o czym tutaj piszę.

Wciąż żywo interesuję się rozwojem Visual Studio, bo jest to naprawdę ciekawy produkt. Tyle tylko, że w mojej opinii ciężki w użyciu w przypadku pisania aplikacji bazodanowych. Posiada jednak ogromną zaletę – wersja community jest za darmo. Tymczasem producent Delphi – firma Embarcadero nie ma w ofercie nic ciekawego. Delphi jest potwornie drogie i raczej tutaj upatruję klęski tego świetnego środowiska, którą sprytnie wykorzystał Microsoft, nie zaś „przestarzałością” samego języka Object Pascal.

578total visits,1visits today

Tagi , .Dodaj do zakładek Link.

Dodaj komentarz

Twój adres email nie zostanie opublikowany. Pola, których wypełnienie jest wymagane, są oznaczone symbolem *

5 + 5 =