Query builder w bibliotece do obsługi bazy danych Opcje

[czychacz]

BoltDB
Pod powyższym linkiem znajduje się kod inicjacyjny dla biblioteki do obsługi bazy danych, którą tworzę. Po co? Żeby poćwiczyć niektóre rzeczy.
Na razie działa tylko budowa prostego SELECTa poprzez klasy Select i SelectAbstract z odpowiednich namespaców.
Chciałbym, żeby ktoś rzucił na to okiem (głównie namespace

BoltDb\Engine\Mysql\Query

i

BoltDb\Engine\Query

). Od siebie mogę dodać, że prawdopodobnie kiepsko wymyśliłem zależności między interfejsami, traitami i klasami abstrakcyjnymi. Jak Wy byście to widzieli?

//edit: Dodałem prosty tekst Readme

Naprawdę nikt nie ma nic do dodania? Czy może mój kod jest tak sh*towy, że nikt nie chce go przeglądać? (IMG:style_emoticons/default/brzydal.gif)

Ten post edytował czychacz 3.08.2017, 15:32:53

[czychacz]

A jak inaczej to rozwiązać? Publiczne settery na zwracanych obiektach? Według mnie to jeszcze gorsze niż 6-7 parametrów do fabryki.

[primosz67]

A jak inaczej to rozwiązać? Publiczne settery na zwracanych obiektach? Według mnie to jeszcze gorsze niż 6-7 parametrów do fabryki.

Według mnie masz parę opcji:

1. Builder

[PHP] pobierz, plaintext 
var userTable =  Table::of("user")
->schema("schema")
 ->primaryKey("id")
 
$select->jouinTable(Table $userTable, "alias")
->joinTable($table, "userId")
[PHP] pobierz, plaintext 

2.

[PHP] pobierz, plaintext 
$select->leftJoinTable("schema.userTable","alias")
 ->on("alias.id", "someTable.userId")
 
->leftJoinTable("schema.games","alias")
 >on("alias.id", "someTable.gameId");
[PHP] pobierz, plaintext 

Generalnie skłaniam się do builderów i fluentApi bo dużo lepiej się je czyta niż settery. Jak masz więcej 5 - 7 parametrów to lepiej utworzyć 1 albo dwie klasy które przyjmują te parametry zgodnie z ich nazwą. W moim przypadku "Table" - posiada rzeczy dotyczące tabeli (nazwa, schema, klucz główny itd) , parametry dotyczące relacji uzupełniam w metodzie joinTable.

Ten post edytował primosz67 5.08.2017, 09:56:42