funktionalität in Konstruktoren ähnlicher Klassen besser machen???

[MB]

moin,

Kontextwechsel

noch nie gehört?

klar und angewendet. Du verwirrst mich. Den Cartoon der Seite den du als Link verwiesen hast, checke ich nich.

Bei Spaltennamen muss man auch aufpassen, Rolf B ist ein völlig korrekter Spaltenname. Aber er grillst Dir dein SQL, wenn Du ihn nicht in Backticks einschließt (MYSQL).

Ich verwende immer Backticks.

new InitDBContextPOPO

Das ist kein POPO. Plain Old * Objects gehören thematisch zum fachlichen Modell.

POPO Klassen haben doch außer dem __construct() keine Methoden und sind readOnly zugänglich. So habe ich es verstanden und das ist hier gegeben

Dein Objekt würde, glaube ich, lieber QueryContext heißen.

Wenn dann SQLContext da ich die Initialisierung mit allen DQL, DML, DDL, DCL mache.

Dein Tables-Array ist - scheint mir - falschrum gebaut. Die Aliasnamen müssen üblicherweise eindeutig sein in einer Query, Tablenamen nicht. Wenn Du einen self join machen musst, geht das bei Dir schief. Es sollte 'tA' => 'tableA' heißen.

nur n Beispiel. Mein Validator erkennt das.

->generalCondition(..., LogicConstant::_NONE)

Warum eigentlich _NONE und nicht NONE?

AND und OR sind Keywords und kann ich nicht nehmen also _AND und _OR. NONE hingegen nicht. Aber es sind nicht ordenlich aus wenn ich bei NONE kein unterstrich mache.

[…] hier würde ein Defaultparameter helfen

is auch drin

Was auch helfen kann, ist ein Set von Helper-Funktionen, die das Erzeugen von Interfaces und Containern kapseln.

Ok hast du ne Lektüre parat?

Dann verschwindet eine Menge Technomantie aus einem Query-Build. Und durch schöne Variablennamen liest sich der Build der Query gleich wie ein Buch.

Ich verschaffe euch mal ein UML Diagramm meines Projektes. Habe ich sowieso vor.

Man nennt sowas ein Fluid Interface - es sieht aus wie flüssige Sprache.

Ok Lektüre?

Die Container sollten übrigens rein binär sein. Ein OR aus mit N Operanden lässt sich immer auf (N-1) ORs mit 2 Operanden zurückführen, und das macht die Programmierung vieeeel einfacher.

War auch nur Beispiel. Ich habs hardgecoded um zu zeigen was die BETWEEN Klasse tun soll.

Warum heißen die Methoden des Querybuilders eigenlich generalXXXX? […] Warum da neue Namen erfinden?

Aggregatoren muss GroupBy haben sonst beißen die sich. daher habe ich das getrennt von ->select() in generalSelect() für CASE usw. und ->groupSelect() für Aggregatoren wie MAX().

Das $builder Objekt sollte übrigens nur die Methoden select, insert, update, delete und union kennen.

bin noch an Coden

Vielleicht kann $builder auch Helper enthalten, die ColumnInterfaces oder LiteralInterfaces erzeugen.Und diese Interfaces können ihrerseits Builder-Helper enthalten:

Wie sähe das wirklich konkret aus??? Hast du n SQL Builder zum Donload oder ist es SecretCode? Dann habe ich nicht gefragt 😉.

Das liest sich jedenfalls besser als deine Comparison Konstruktion.

ok

Wichtig ist da auch eine API Konsistenz.

Lektüre und Referenzen hast du?

Es ist merkwürdig, wenn ein LogicContainer die LogicConstant am Ende hat und eine Comparison die „EquotiationConstant“ (das Wort gibt's nicht) vorn. Diese Constant möchte vermutlich lieber ComparisonOperator heißen…

Konkretes Beispiel:

class EquotationConstant {
  const
    EQUAL = '=',
    NOT_EQUAL = '<>'
    GREATER_THAN = '>'
    LESSER_THAN = '<';
}

desweiteren noch ArithmeticConstant +-*/ usw.

was meinst Du mit manuelle Formatierung

Ich meinte die von Dir überall verstreuten Aufrufe von toString oder auch getResult. Sowas sollten die Builder-Komponenten bei Bedarf selbst tun.

es gibt kein __toString() sonder allefals $expression->getString() für den SQL Schnipsel und $expression->getValues() für ersetzungen der ? in der WHERE-Clausel.

lgmb