nicht angemeldet
Hi!
..database
beinhaltet eine Klasse MyDB die PDO instanziert.
Dazu ein Klasse die mir per Aliasname einen SQL Befehl zurück liefert der im Unterverzeichnis "sql" von "database" in einer Datei "Aliasname.sql" steht.
Du sammelst also an einer separaten Stelle alle SQL-Statement-Strings, so dass du an mehreren Stellen arbeiten musst, wenn du mal beispielsweise einen Parameter hinzufügen willst. Im SQL-String den Platzhalter einfügen und anderswo das Handling dazu. Das klingt unübersichtlich.
Alles in Klassen zu packen und dann bei den Templates eine Ausnahme zu machen ist doch auch irgendwie "doof" :)
Nicht "doofer" als dass ein Controller mit Eingabedaten, ein Model mit einer Datenbank und eine View mit Template-Dateien hantiert. Vermutlich wirst du aber einige Hilfsfunktionen in der View haben wollen, die sich zum Beispiel um das korrekte Behandeln von Werten beim Einfügen in das Template beschäftigen, die HTML-Elemente (für Formulare oder Datagrids vielleicht) erstellen, und so weiter. Da brauchts dann Code dafür, der auch gut in Klassen untergebracht werden kann.
Schau mal übern Tellerrand :-) und dir ASP.NETs MVC-Implementation an. Bei jenem Tutorial reicht es, wenn du es überfliegst. Projekt erstellen, Datenbank erstellen - geschenkt. Model erstellen geschieht auch mit Clicks, das Ergebnis ist automatisch generierter Code (für das einfach Beispiel als Model ausreichend) - ebenfalls geschenkt. Controller erstellen - eine Menge selbst geschriebener C#-Code. Dann kommt die View, um die Datensätze zu listen. Und die ist erst einmal nur ein Template mit eingestreutem Code, quasi PHP-like. Aber auch da steckt eine Klasse dahinter, wie am Anfang von Listing 3 mit Inherits="System.Web.Mvc.ViewPage<...> zu sehen ist. Dieses Template wird von .NET beim ersten Request in C#-Code übersetzt und compiliert. Auf den ersten Blick sieht eine View anders aus als M und C, dem Prozessor und dem Seitenbesucher ist das aber letztlich egal. Der Rest vom Tutorial behandelt das Bearbeiten von Daten - eine Wiederholung von Controller- und View-Bearbeitung - auch geschenkt.
Im Allgemeinen kann man Interfaces verwenden, wenn die Funktionalität gleich bleiben soll, die Implementation aber grundverschieden gelöst werden soll. Ansonsten reicht eine Basisklasse mit Ableitungen.
Das wäre doch bei meinem Model usw. der Fall oder? Die Daten können ja über unterschiedlichste Wege kommen. z.b. BestandModel aus der DB und UserModel aus einer Textdatei. Wenn ich das sicher programmieren möchte wäre doch hier ein Interface angebracht weil eine Basisklasse dafür dann wohl nicht geeignet wäre?
Was ist das gemeinsame zwischen deinen Models? Welche Methoden sollen denn alle Models gemeinsam haben? getData()? Scheint mir nicht sehr sinnvoll zu sein. Üblicherweise behandelt jedes Model ein eigenes Thema mit von den anderen Models unterschiedlichen Datenstrukturen (getPerson(), getCompany(), getWhatever()). Eine View ist auch auch spezialisiert auf die Daten, die sie bekommt und kann kaum pauschal aus einem beliebigen Model Content erstellen.
Ich wollte es halt gleich richtig machen wenn ich mir schon mal die Mühe mach.
Gleich richtig bedeutet nicht, aufblähen nur weil es geht. Performant muss es am Ende einerseits sein, wartbar andererseits. Kompromisse zu suchen bleibt da nicht aus.
Lo!