2012-01-01 10 views
8

Mówiąc prościej o implementacji Table Data Gateway (TDG): tworzysz oddzielną klasę TDG, która zawiera SQL dla operacji CRUD z konkretną tabelą. Zatem modele nie komunikują się bezpośrednio ze źródłem danych (na przykład z bazą danych), ale za pośrednictwem tych abstrakcyjnych - klas TDG. Jest to po prostu podejście do robienia kolejnego poziomu abstrakcji, a to tylko opakowanie do komunikacji z bazą danych - pobieranie i modyfikowanie danych. Klasy IMHO TDG nie powinny zawierać członków, tylko metody. Oto dobry schemat wizualizujący użycie TDG pattern. Podczas korzystania z podejścia TDG, SQL powinien zostać przeniesiony z klas modelu do klas źródła danych (TDG). Wszystkie dane pobierane z DB przez klasy TDG są przechowywane w moich modelach.W jaki sposób implementacja Table Data Gateway różni się od Active Record?

A co z aktywnym wdrażaniem rekordów? Gdybym scalił dostęp do danych i moją klasę modelu w jedną klasę modelu, to czy zaimplementowałem aktywny rekord? Nie byłem w stanie znaleźć wyraźnego rozróżnienia lub jak te wzorce wyglądają w PHP i różnią się od siebie.

Często mam jedną pojedynczą klasę bazy danych, a następnie oddzielną klasę modelu dla każdej tabeli bazy danych. Każda klasa modelu ma CRUD + kilka operacji niestandardowych (count, avg itp.). Niektóre klasy mają członków do utrzymania wyników z CRUD lub niestandardowych operacji - to się dzieje w razie potrzeby. Czy to podejście można uznać za aktywny rekord? Ponadto, jeśli przenieść SQL z moich klas modelu do klas TDG byłby to Table Data Gateway?

Odpowiedz

14

Od http://martinfowler.com/eaaCatalog/index.html

Table Data Gateway: obiekt, który działa jako brama (466) do tabeli bazy danych. Jedna instancja obsługuje wszystkie wiersze w tabeli.

enter image description here

Active Record: Obiekt, który zawija wiersz w tabeli bazy danych lub widoku, obudowuje dostęp do bazy danych i dodaje logikę domeny na tych danych.

enter image description here

Oczywistą różnicą głównym jest to, że TDGs owinąć dostęp do tabeli i zwraca tylko wiersz danych, natomiast ARs owinąć dostęp do rzędu w tabeli i dodaje logikę biznesową do to.

Jeśli nie masz bardzo niskiego niedopasowania impedancji, preferujesz TDG, ponieważ w przypadku AR obiekty biznesowe/domeny są zgodne ze strukturą w bazie danych, co zwykle nie dotyczy sposobu modelowania twoich obiektów domenowych. Rząd może wiedzieć, jak przetrwać, ale Osoba nie powinna wiedzieć. Na dłuższą metę można go dłużej utrzymać, aby oddzielić logikę trwałości od logiki domeny.

Odnośnie twojego obiektu Singleton DB spójrz na Is there a use-case for singletons with database access in PHP?.

+0

Dzięki. Jakie typy metod (i zapytania SQL) mogę mieć przy wdrażaniu TDG? Nie powinienem logiki biznesowej, ale co może być uznane za logiki biznesowej? Na przykład, czy mogę mieć takie metody (i zapytania SQL) w klasach TDG, takich jak selectAllRows, aktualizacja wsadowa (przekazywanie tablicy danych), selectAllPersonsByLastName, countAll, SelectAvg i etc? IMHO wszyscy powinni mieszkać w klasie TDG. Czy logika biznesowa oznacza jakiekolwiek dodatkowe obliczenia wykonane z uzyskanego zestawu wyników SQL z klasy TDG? – Centurion

+0

@Centurion a TDG może zawierać wszystkie kwerendy SQL powiązane z tabelą: wstawia, aktualizuje, wybiera (logika trwałości).Nie powinien zawierać kodu przetwarzającego wyniki zapytania (logika biznesowa). Umieść to w [Modelu domeny] (http://martinfowler.com/eaaCatalog/domainModel.html) lub [module tabeli] (http://martinfowler.com/eaaCatalog/tableModule.html) – Gordon

+0

Masz pomysł:) ale mam jeszcze jedno pytanie. Jedna klasa modułów tabeli jest mapowana do jednej tabeli, więc taka klasa modułu tabeli IMHO może być uznana za model (gdy rozmawia się w kontekście MVC)? A co z modelem domeny, co należy wtedy uznać za model? Grupa klas, które są używane do kontrolera betonu? – Centurion

Powiązane problemy