Es gibt mMn kein pauschales Best-Practice.
Beispiel:
Ich habe TTable nur ganz am Anfang mal ausprobiert und festgestellt, dass es für mich unbrauchbar ist. Aber kürzlich hatte ich eine kleine Anwendung, für die ich es dann doch verwendet habe, weil es die effizienteste Lösung war. Ich brauchte auf jeden Fall alle Datensätze (bis zu 400.000). Eine Visiualsierung war nicht erforderlich. In dem Fall eine einfache und praktikable Nutzung von TTable, um eine schnelle Lösung zu haben.
Fast alle Anwendungen, die ich programmiere, sind Inhouse-Anwendung (
DB-Server im externen RZ mit GBit-Leitung). Das meiste ist dabei Read-Only. Die meisten der existierenden Anwendungen wurden vor meiner Zeit in der Firma entwickelt. Zu der Zeit gab es kein Live-Binding, wie es heute verfügbar ist. Also wurden oft datenbanksensitive Komponenten eingesetzt. Vieles wurde in Grids dargestellt. Der Komfort eines TDBGrids (oder bessere Third-Party-Komponenten), ist nicht zu unterschätzen. Wenn die Liste einfache Infos aus einen Master-Tabelle benötigt, sind das idR auch
DB-Komponenten. Sobald aber mit den Daten "gerechnet" wird, gibt es ein Interface und
DB-Komponenten haben sich erledigt.
Sobald es um Anwendungen geht, die nicht Read-Only sind, sieht die Situation anders aus. Direkte Erfassung in
DB-Komponenten sind dann die Ausnahme. Ganz besonders, wenn Plausibilitätsprüfungen erforderlich sind, was bei uns die Regel ist. Da ist ein Interface dann deutlich einfacher, als mit
DB-Komponenten.
Zum Thema Filter:
Ist bei mir ein NoGo. Da ich fast ausschließlich TQuery verwende, kann ich die Filter auch gleich in die
SQL-Abfrage einbauen. Wenn ich alte Projekte von meinen Vorgängern öffne, bin ich jedesmal am Fluchen, wenn ich wieder über Filter stolpere. Warum soll ich erst Daten von der
DB holen, wenn ich die dann wieder einschränke? Dann kann ich auch gleich einschränken.