Sie möchten nicht, dass Ihre Präsentationsebene direkt von Ihrer Datenbankstruktur abhängt; Das Problem dabei ist, dass sich Ihre Darstellungsschicht ändern muss, wenn sich Ihre Datenbankstruktur ändert, was auf lange Sicht zu Problemen führt. Darüber hinaus sind Sicherheitsprobleme damit verbunden, dass Ihre Präsentationsebene direkt mit Ihrer Datenbank interagieren soll.
Die grobe Analogie ist hier zu Märkten; Wenn du in den Laden gehst, um einen Laib Brot zu kaufen, musst du nicht wissen, wie man Weizen anbaut; Alles, was Sie wissen müssen, ist, dass Sie Geld haben, und sie haben Brot, und dass sie eine bestimmte Menge Brot für eine bestimmte Menge Geld eintauschen werden. Sie müssen nicht wissen, zu welcher Jahreszeit der Weizen gepflanzt wird, oder wie Sie die Spreu entfernen können, weil die Rückschicht das für Sie übernimmt. In ähnlicher Weise muss der Bauer nicht wissen, wie er einem ganzen Haufen von Menschen Brot verkaufen oder sogar Brot backen kann. alles, was er tun muss, ist zu wissen, wie man Weizen anbaut.
Die Philosophie des modernen Designs empfiehlt, dass Sie eine Zwischenschicht verwenden, um zwischen Ihrer Präsentationsschicht und Ihrer Datenbankschicht zu interagieren. Hier setzen Sie Ihre Geschäftslogik. Nehmen wir zum Beispiel an, dass Sie Widgets auf Ihrer Website verkaufen. Anstatt dass Ihr Präsentationscode die Datenbank nach Widgets abfragt und diese anzeigt, haben Sie ein Business-Objekt, das Ihre Widgets verwaltet.Auf diese Weise muss Ihr Geschäftsobjekt wissen, wie Ihre Datenbankstruktur aussieht, aber Ihre Präsentationsebene muss nur wissen, wie Sie Ihr Geschäftsobjekt nach einer Liste mit Widgets zur Anzeige stellen können. Noch wichtiger ist, dass Sie in Ihrem Geschäftsobjekt die Regeln platzieren können, die aufgerufen werden sollen, wenn bestimmte Dinge passieren. Anstatt Ihre Präsentationsschicht direkt Änderungen an der Datenbank für Inventar und Bestellungen vorzunehmen, wenn eine Bestellung getätigt wird, weiß Ihr Geschäftsobjekt, wie die Änderungen vorgenommen werden und welche Tabellen geändert werden müssen, wenn Ihre Präsentationsebene einen Verkauf anfordert.
Auf diese Weise trennen Sie die Anzeige Ihrer Informationen von der Persistenz und der Logik, die der Website zugrunde liegen. Es geht um eine gute Planung. Insbesondere müssen Sie herausfinden, was Ihre Website zu einem bestimmten Zeitpunkt tun wird, und was das bedeutet in Bezug auf welche Schnittstellen Ihre Geschäftsobjekte bieten. Dann implementieren Sie Ihre Geschäftsobjekte basierend auf diesen Anforderungen. Diese Business-Objekte sind, wo Sie das Wissen über die Datenbankstruktur und Ihre spezifische Geschäftslogik eingeben ("wenn A passiert, tun Sie B und dann C", etc.).
Das scheint am Anfang viel Arbeit zu sein, aber es lohnt sich wirklich.
Also, was ist die Verwendung von Bindung und anderen Datenfunktionen in Visual Studio und .NET? Wenn Sie eine "Datenzugriffs" -Layer verwenden, um die Präsentationsebene zu füttern, würden Sie nicht den Großteil des Codes von Grund auf in der Datenzugriffsebene schreiben? – Pete
Keine Verwendung. Seit der Einführung - lange vor .NET - habe ich immer das Gefühl, dass die bindenden Front-End-Steuerelemente direkt an die zugrunde liegende Datenbank böse sind. Nur meine Meinung, natürlich .... – RolandTumble
In Ordnung, also würde ich eine Klasse von Grund auf neu schreiben wollen, um mit der Datenbank und einer anderen Klasse für Kunden zu interagieren, die meine Datenbankklasse verwenden würden, um seine Felder zu füllen? Dies wird gegenüber dem Werfen einiger Textfelder und Beschriftungen auf ein Formular und dem Binden der Steuerelemente bevorzugt. – Pete