Warum verwenden wir in Zend die DB -Modellklasse und die Mapper -Klasse als zwei separate?

StackOverflow https://stackoverflow.com/questions/9329881

Frage

Ich arbeite an dem Zend -Projekt, ich beziehe mich auf ein anderes Zend -Projekt, um das neue Zend -Projekt zu erstellen. Aber ich möchte dieses Projekt nicht blind verfolgen, ohne zu verstehen. In der Zend -Verzeichnisstruktur gibt es in der Modellklasse hauptsächlich zwei Arten von Klassen, die ich sehe, wie in

- models
   - DbTables
        - Blog.php  //Extends Zend_Db_Table_Abstract
   - Blog.php       // Contains methods like validate() and save()
   - BlogMapper.php // Also Contains methods like validate(Blog b) & save(Blog b)

Warum wird diese spezifische Struktur befolgt? Ist dies dazu, Objektklassen- und Datenbankmodellklasse zu trennen?

Bitte erkläre.

War es hilfreich?

Lösung

DataMapper ist ein Designmuster aus Mustern der Enterprise -Anwendungsarchitektur.

Der Data Mapper ist eine Softwareebene, die die In-Memory-Objekte von der Datenbank trennt. Seine Verantwortung ist es, Daten zwischen den beiden zu übertragen und sie auch voneinander zu isolieren. Mit Data Mapper müssen die In-Memory-Objekte nicht wissen, dass eine Datenbank vorhanden ist. Sie brauchen keinen SQL -Schnittstellencode und sicherlich keine Kenntnis des Datenbankschemas.

Wie Sie Daten in einer relationalen Datenbank speichern, unterscheidet sich normalerweise von der Art und Weise, wie Sie Objekte im Speicher strukturieren würden. Beispielsweise hat ein Objekt ein Array mit anderen Objekten, während in einer Datenbank Ihre Tabelle stattdessen über einen Fremdschlüssel für eine andere Tabelle verfügt. Wegen dem Objektrelationsimpedanz-Missverhältnis, Sie verwenden eine Vermittlungsschicht zwischen dem Domänenobjekt und der Datenbank. Auf diese Weise können Sie beide weiterentwickeln, ohne den anderen zu beeinflussen.

Die Trennung der Zuordnungsverantwortung in seiner eigenen Ebene folgt auch näher der Einzelverantwortungsprinzip. Ihre Objekte müssen die DB -Logik nicht wissen und umgekehrt. Dies gibt Ihnen beim Schreiben Ihres Codes eine größere Flexibilität.

Wenn Sie kein Domänenmodell verwenden möchten, benötigen Sie normalerweise kein DataMapper. Wenn Ihre Datenbanktabellen einfach sind, sind Sie möglicherweise besser mit einem Tablemodul und einem tabbenen Datenway oder sogar Activerecord.

Für verschiedene andere Muster sehen Sie meine Antwort auf

Andere Tipps

Die Idee eines Modells besteht darin, die logische Sammlung von Daten in Ihrem Code abzuschließen.

Die Idee eines DataMapper besteht darin, diese Datensammlung auf Anwendungsebene mit dem Speichern von Daten in Beziehung zu setzen.

Für viele Implementierungen von ActiveCord bietet der Rahmen diese Absicht nicht und dies kann zu Problemen führen. Zum Beispiel kann ein Blogpost -Modell die grundlegenden Informationen eines Blog -Beitrags wie abschließen

  • Titel
  • Autor
  • Karosserie
  • Datum der Veröffentlichung

Aber vielleicht möchten Sie auch, dass es so etwas enthält wie:

  • number_of_reads
  • number_of_likes

Jetzt können Sie alle diese Daten in einer einzigen MySQL -Tabelle von Anfang an speichern, aber wenn Ihr Blog wächst und Sie super berühmt werden, finden Sie heraus Ein separater Datenbankserver.

Wie würden Sie diese Felder der Blogpost -Objekte in einen anderen Datenspeicher migrieren, ohne Ihren Anwendungscode zu ändern?

Mit dem DataMapper können Sie die Art und Weise ändern, wie das Objekt in den Datenbank (n) gespeichert wird, und die Art und Weise, wie es aus den Datenbank (en) geladen wird. Auf diese Weise können Sie den Speichermechanismus optimieren, ohne die tatsächliche Sammlung von Informationen ändern zu müssen, auf die Ihre Anwendung angewiesen ist.

Lizenziert unter: CC-BY-SA mit Zuschreibung
Nicht verbunden mit StackOverflow
scroll top