Korzystanie z komponentów Delphi data-aware-plusy i minusy [closed]

Po wypróbowaniu zarówno danych-aware i nie danych-aware stylu aplikacji Delphi jestem z powrotem w obozie komponentów data-aware te dni. Poprawna warstwa kodu wymaga trochę pracy i dyscypliny, ale i tak jest szybsza niż robienie wszystkiego ręcznie przy użyciu kontrolek nieobsługujących danych.

Kilka moich porad dotyczących użycia komponentów opartych na danych to

• Nie tylko przepisuj FishFact na większą skalę. Przemyśl swój projekt.

• Nie używaj TDataModule, używaj wielu Tdatamodule, każdy odpowiedzialny za mały aspekt danych aplikacji.

• TDatasets należą do TDataModules, podczas gdy TDataSources należą do TForms (chyba że są używane dla relacji master / detail).

• Używaj zestawów danych w pamięci, takich jak DataSnap TClientDataSet.

• Twój ClientDataSets nie musi dokładnie odzwierciedlać tabel bazy danych. DataSnap umożliwia masowanie struktur danych w pamięci, dzięki czemu można tworzenie zestawów danych dostosowanych do konkretnych celów. W szczególności możesz robić takie rzeczy jak

  • Łączenie dwóch lub więcej tabel w jeden edytowalny zbiór danych

  • Denormalizacja struktur tabeli szczegółów Głównych może czasami uprościć kod interfejsu użytkownika.

  • Tworzenie pól tylko w pamięci (jak pola obliczeniowe, ale można do nich również pisać)

• Zagnieżdżone tabele tclientdataset są przydatne, ale nie jedyny sposób na wyrażenie szczegółów master związki. Czasami lepiej jest zrobić to w stary sposób z dwoma niezależnymi TClientDataSets połączonymi przez TDataSource.

Spójrz na rozwiązania ORM.

To ładne podejście do architektury wielopoziomowej. Zobacz ORM dla DELPHI win32

Kontrolki data aware są świetne, ale musisz upewnić się, że Twój kod biznesowy znajduje się w oddzielnej warstwie.

To nie jest trudne, ale musisz być świadomy, jak możesz to zrobić.

Jednym z podejść jest posiadanie komponentów zestawu danych w DataModule (lub innym kontenerze niewizualnym).

Kolejną przydatną sztuczką jest użycie tclientdataset do wykonania wpisu UI i użycie go jako pośredniego bufora między interfejsem a warstwą biznesową. Warstwa biznesowa następnie korzysta z TDataSet komponenty specyficzne dla warstwy danych.

--jeroen

Komponenty bazodanowe Delphi nie zależą od silnika bazodanowego, którego używasz, więc korzystanie z Firebird lub MS SQL Server lub Oracle lub innych nie ma znaczenia dla komponentów bazodanowych. Znają tylko przypisany im komponent datasource i robią za jego pomocą wszystkie rzeczy związane z DB.

Dla mnie, jeśli coś da się zrobić z komponentami świadoma danych w przyjemny sposób, będę z nich korzystał. Są to zazwyczaj małe projekty, które należy wykonać w krótkim czasie. W większych projektach I może całkowicie wykluczyć komponenty świadome danych lub używać ich w formularzach, które są używane tylko do prezentacji danych i nie otrzymują danych wejściowych użytkownika. Jeśli chodzi o odbieranie danych wejściowych użytkownika, mogę używać komponentów Nie świadomych danych, ponieważ mam większą elastyczność w kontrolowaniu ich i walidacji danych wejściowych. Oczywiście komponenty data-ware mogą być nadal przydatne w takich scenariuszach zbyt. Nadal możesz zweryfikować dane wejściowe użytkownika w zdarzeniach zestawu danych, takich jak OnBeforePost. Również jeśli używasz projektu wielopoziomowego, a twój Klient aplikacja reprezentuje warstwę prezentera danych, walidacja danych wejściowych odbywa się w warstwie średniej, dzięki czemu można odbierać dane wejściowe za pomocą komponentów obsługujących dane w aplikacji klienckiej i wysyłać je do warstwy średniej w celu weryfikacji i dalszego przetwarzania.

Komponenty obsługujące dane są przydatne z perspektywy RAD i prototypowania, zwłaszcza gdy projektujesz raporty lub siatki oparte na danych. czyli możesz majstrować w czasie projektowania. Więc używam ich w ten sposób. Ale kiedy przychodzi czas, aby przekształcić go w kod wysyłkowy, prawie zawsze zrywam połączenia, usuwam SQL z zapytań i robię wszystko w kodzie. W ten sposób jest znacznie bardziej przewidywalny i możliwy do utrzymania, szczególnie w środowisku dla wielu programistów z kontrolą wersji. Kiedy SQL jest osadzony gdzieś w formularzu, to duży ból, aby spróbować dowiedzieć się, gdzie faktycznie znajduje się SQL. A szczególnie źle jest mieć SQL w dwóch miejscach, a następnie trzeba dowiedzieć się, który jest w efekcie.

Możesz użyć Unidac który obsługuje wiele serwerów bazodanowych, w tym Firebird (którego używam) i ma bardzo ładne funkcje.

W połączeniu z Remobject SDK {[2] } będziesz miał ładne połączenie architektury warstwy n i abstrakcji bazy danych.