Lemmy schrieb dazu:
Zitat:
Desweiteren kannst Du die Abhängigkeit von den Komponenten auflösen, indem Du deine Anwendung entsprechend aufbaust und eine Mehrschicht-Architektur verwendest. Somit kannst Du im Notfall die komplette
VCL-Oberfläche wegwerfen und eine ASP.NET Oberfläche dran basteln, ohne Änderungen an der GEschäftslogig vornehmen zu müssen, weil diese in entsprechende Klassen gekapselt ist und nichts mit der Oberfläche zu tun hat.
Diese Aussage entspricht voll und ganz meiner Meinung. Ich möchte sie an dieser Stelle nur noch etwas erweitern: Gliederst Du Deine Anwendung wirklich konsequent in mehrere Schichten oder Ebenen, dann bist Du frei in fast allen Belangen: Frontend ist Frontend, die Geschäftslogik ist in einer Ebene gekapselt und darunter liegt eine Schicht, die wie auch immer, die benötigten Daten bereit stellt.
Ich ertappe mich immer wieder dabei, nicht konsequent mehrschichtig zu programmieren, bei mir wirds meist aus Bequemlichkeit ein Monolith oder ein 2Tier. Das ist aber auch nur so, weil die Anforderungen an meine Programme diese Vorgehensweise implizierten (keine Skalierbarkeit benötigt, Single-User-Anwendungen, maximale Performance durch Weglassen von Overhead). Interessant wäre meiner Meinung nach noch die Frage: Soll das Ganze auch noch ins Internet? (Nur so ein Gedanke). Dann solltest Du in jedem Fall auch noch
MYSQL in Deinen Katalog aufnehmen. Auf die Gefahr hin, dass ich über das Ziel hinausschiesse: Wenn Du den
SQL-Server zu reinen Datenhaltung nutzt, ohne darin groß mit Stored Procedures rumzumachen, ist fast jeder der Server eine gangbare Alternative. Wenn man sich dann noch an
Ansi-
SQL hält, ist man fast auf der sicheren Seite. Zum Entwickeln würde ich
IB oder
FB empfehlen. Da Du mit nicht unbedingt großen Daten arbeiten willst und ich davon ausgehe, daß die meisten Datenbankzugriffe eher lesend sind und ich weiterhin davon ausgehe, dass nicht mehr als 2-5 Benutzer auf der
DB rumhacken, bleibt es dabei:
IB oder Firebird. Wenn Internet dazu kommt, sollte man an
MySQL denken.