Persist Abstrack Layer Opcje

[Matrix12]

Mam pytanie odnośnie podejścia do persist abstract layer. Chce stworzyć własną warstwę perystencji oparta o symfony. Moje zalozenie jest takie, że jeżeli Klient zechce zmienić doctrine ORM na coś innego to nie chce aby aplikacja sie rozwalila. Chce zrobić to tak ze utworze abstrakcyjna klase do której wstrzykne doctrine i utworze kilka metod np. find ($ id) w tej metodzie bede korzystał z doctrine i repozytorium. System będzie uzalezniony od moich metod a nie Doctrine.. czy ten kierunek jest odpowiedni coś powinienem zmienic?


Bede wdzięczny za pomoc.

[CuteOne]

Jeżeli widzisz w tym jakiś głębszy sens to oki ale czy zdajesz sobie sprawę, że:
- Metod jest troszkę więcej niż find() czy persist(), i nadpisywanie ich to kawał roboty
- Jeżeli będziesz w przyszłości próbował wykorzystać inny ORM, to może nie być wcale takie proste np. użycie kilka razy flush() w jednej transakcji wrzuca na stos "zadnia" w zadanej kolejności - czy inny ORM będzie robił to samo?

Dla mnie nie ma to najmniejszego sensu (IMG:style_emoticons/default/wink.gif) jeżeli miałbym przewidywać "co w przyszłości, może klientowi strzelić do łba", to nigdy nie skończyłbym żadnego projektu..

[Xelah]

Ja w tym nie widzę niczego nadzwyczajnego. To jest zupełnie normalne podejście do tematu. Model domeny nie ma prawa wiedzieć niczego o persistence.

To persistence zależy od modelu a nie model od persistence. Możesz warstwie persistence może użuć sobie Doctrine czy Propela albo dowolnego innego rozwiązania. Oczywistym jest, że zmiana, na przykład, Doctrine na Propel to nie zadanie na dzień czy dwa ale to nie ma prawa wþlywac na model domeny. Czyli takie rozdzielenie warstw ma jak najbardziej sens, ale wszystko zależy od wielkości projektu. Jak masz do napisania prostego bloga, gdzie logiki biznesowej prawie nie ma, to nie widzę większego sensu. Ale jak piszesz aplikację typu ecommerce czy klasy enterprise, to nawet nie wyobrażam sobie nie rozdzielenia tych warst.

Model to nie baza danych i łączenie ich ma rację bytu tylko jesli model jest na prawdę prymitywny. W każdym innym przypadku model nie ma prawa wiedzieć niczego o persistence.

Pierwszy przykład z brzegu: możesz na przykład zrobić własne klasy repository z interfejsami, które później wstrzykujesz do modelu, żeby zapewnić wymaganą funkcjonalność.

Poczytaj o enterprise architecture. Metod na rozdzielenie tych warst jest całe multum.

[Matrix12]

Możecie mi os polecić opartego o PHP / Symfony2

[Xelah]

Tutaj nie znajdzesz gotowców. Niestety to jest coś, co zależy w 100% od logiki biznesowej. Nie ma tutaj gotowaca, którego sobie zainstalujesz i śmiga.
Niestety takie rzeczy trzeba oprogramować samemu z zależności od potrzeb.

[Matrix12]

Największy problem to perystencja i wszelkie joiny.. Samo pobranie danych jest okej..

[Xelah]

Nie bardzo rozumim... co jest dokładnie problemem?

[ctom]

może to Cię zainspiruje 4Developers2015: Overly Attached ORM (W. Chojnacki)