it-swarm.com.de

Model's getItem (): objektorientiert oder traditionell

Stellen wir uns vor, wir haben eine kundenspezifische Komponente ähnlich einem kleinen Laden, der viele Produkte enthält. Die Datenbank ist sehr relational. Nun wollen wir die Liste aller Produkte in unserem Shop mit der Methode getListQuery() des überschriebenen Modells anzeigen. Dort haben wir Abfrage mit mehreren Joins. In view.html.php Rufen wir alle Elemente mit $this->get('items') ab und alles ist bereit, Daten zu präsentieren. Dies ist Option 1.

Ich habe die Idee, es objektorientierter zu machen. Dies bedeutet, dass getListQuery() keine Relationen verwendet, um zusätzliche Daten zu erhalten, die das Produkt beschreiben. Es werden nur PK und Spalten aus der Produkttabelle abgerufen. Nun überschreiben wir das getItems() des Modells.

public function getItems() {
        $items = parent::getItems();
        for($i=0;$i<count($items);++$i){
            $Product = JTable::getInstance('Product');
            $Product->bind($items[$i]);
            $items[$i] = $Product;
        }
        return $items;
}

Jetzt ist jedes Element eine Instanz von OurComponentTableProduct. Diese Tabelle enthält Getter, um Produktdaten abzurufen, die sich in einer anderen Tabelle befinden. Direkt im Blick verwenden wir Getter für einige Daten, zum Beispiel getName() oder getCategory(). Dies ist meine 2. Option.

Wie Sie sehen können, ähnelt die zweite Option Entity oder Java DAO (ich denke schon). In diesem Fall ist unsere Entity die Table-Klasse. Außerdem denke ich, dass sie elastischer und eleganter ist. Ich verstehe Hier ein Nachteil, der durch zusätzliche Datenbankabfragen verursacht wird: Beispielsweise befinden sich die Produktpreise in einer anderen Tabelle als die Produktprimärdaten und diese Tabellen haben die Beziehung product_id-product_id. Mit der ersten Option können wir nur die Tabelle mit den Preisen verbinden und die Spalte auswählen. In der zweiten Option Wir schreiben eine getPrice Methode, die eine Abfrage erstellt und den Preis abruft. Jeder Artikel führt eine eigene Abfrage durch. Bei der ersten Option wird alles in einer Abfrage abgerufen.

Natürlich haben wir Sicht mit Produktdetails. Hier können wir wieder eine große Abfrage schreiben, um dieses Produkt abzurufen (DRY-Regel), aber wir können auch unser OurComponentTableProduct verwenden. Einfach per PK laden und das ist alles.

Die Leistung ist für mich sehr wichtig, da ich gerade eine große Komponente mit einer großen Anzahl von Zeilen in db entwickle: Hunderttausende in jeder relationalen Tabelle.

Was ist Ihrer Meinung nach die bessere Lösung und warum?

2
turson

Ich würde vorschlagen, dass Sie gemischte Versionen beider Fälle verwenden.

  1. Produkt und zugehörige Informationen in einer Join-Abfrage
  2. Produktstatistiken wie verkaufte Artikel usw., die nicht mit einer anderen getXXX-Methode an einer einzelnen Abfrage teilnehmen können.

Java DAO-Frameworks wie Hibernate und die Joomla-Datenbank-API sind zwei völlig unterschiedliche Ansätze. Joomla-Datenbankabfragen (mit Modell) funktionieren mit einzelnen Abfragen. Wenn Sie mehrere Funktionen für verschiedene Tabellen verwenden möchten, treten nur wenige Probleme auf.

  1. Joomla Model wurde entwickelt, um eine einzelne Abfrage zu erhalten und ein Ergebnis dafür abzurufen. Das heißt, die Abfrage ist an Ihr Modell gebunden. Wenn Sie zwei verschiedene Methoden verwenden möchten, nämlich getProduct und getPrice, müssen Sie für beide Methoden eine eigene Implementierung für das Abrufen von Abfragen schreiben. Am Ende fügen Sie also für jeden Datensatz ein eigenes Modell hinzu.

  2. Sie überschreiben JModelList, um die Liste der Produkte abzurufen. So sind Ihre anderen Objekte wie Paginierung, Filter, Formulardaten - alle an Ihr Modell gebunden. Sie müssen also wieder alles manuell erledigen, anstatt einfach die in JModelList definierten übergeordneten Methoden zu verwenden.

  3. Leistung - Dies hängt von vielen anderen Faktoren ab, wie z. B. Ihren Indizes, der Anzahl der vorhandenen Daten usw. Das Abrufen einfacher Ergebnisse aus einer Tabelle wird immer schneller geladen als ein Join. Sie verlieren jedoch die Flexibilität, komplexe Abfragen zu erstellen, und zwar, indem Sie die Liste mithilfe von Joins verfeinern. Außerdem müssen Sie alle WHERE-Klauseln erstellen, die für jede einzelne Abfrage spezifisch sind, wenn Sie keine Verknüpfung verwenden. Ein Join wird im Speicher der Datenbank ausgeführt, und einzelne Abfragen erfordern mehrere Aufrufe der Datenbank. Eine gut optimierte Datenbank ruft die Ergebnisse schneller ab, wenn Join-Vergleiche mit mehreren Einzelergebnissen durchgeführt werden. Fügen Sie den Netzwerk-Overhead hinzu, wenn sich Ihre Datenbank auf einem anderen Server befindet, z. B. mit Amazon RDS.

  4. Nicht alle Ergebnisse können mithilfe mehrerer einzelner Abfragen abgeleitet werden. Sie werden am Ende nicht benötigte Daten abrufen, nur um den erforderlichen Datensatz herauszufiltern. Beispielsweise,

    ein. Ich möchte eine Liste der Produkte, die vor 10 Tagen verkauft werden.

    b. Produkte in einer Tabelle und Transaktionen in anderen

    Wie können Sie nur Produkte erhalten, die vor 10 Tagen verkauft wurden, ohne Joins zu verwenden?

Aus allen obigen Gründen würde ich sagen, dass das Schreiben einzelner Abfragen für einzelne Datensätze keinen zusätzlichen Vorteil bringt.

2
Nagarjun