Warstwa DAO w frameworku MVC? Opcje

[Demoneos]

W artykule Frameworki dla PHP, czyli wydajne tworzenie aplikacji na stronie Podsumowanie na schemacie architektury frameworda widać, że z każdą klasą modelu połączoną jest jedna klasa typu DAO. W artykule tym jest również napisane:

Model

Również w warstwie modelu jest coś, co moglibyśmy udoskonalić. Najpierw jednak kilka słów o klasie NewsModelDao. Jej nazwa nie została wybrana przypadkowo, ponieważ skrót DAO pochodzi od kolejnego wzorca projektowego - ang. Data Access Object. Opisuje on sposób dostępu do trwałego źródła danych (najczęściej będzie to baza danych). Zgodnie ze wzorcem DAO cała logika dostępu do zewnętrznych danych konkretnego typu jest zamknięta w jednej klasie. Takie podejście daje nam kolosalne korzyści. Po pierwsze, dla obiektów korzystających z DAO zupełnie obojętne jest, skąd pochodzą dane. Pozwala to zmieniać miejsce przechowywania informacji bez naruszania pozostałych fragmentów kodu. Wyobraźmy sobie sytuację, w której poproszono nas by aplikacja, którą stworzyliśmy, pobierała od dzisiaj dane o użytkownikach nie z bazy danych, ale z webserwisu. Jeśli kod dostępu do danych użytkowników był rozrzucony w wielu skryptach, czeka nas wiele pracy polegającej na przepisywaniu i testowaniu całego rozwiązania. Przy wykorzystaniu DAO również musimy się trochę napracować, ale zadanie jest znacznie łatwiejsze do wykonania.

DAO jest jedyną częścią aplikacji, która zawiera kod związany z konkretną składnicą danych. Dzięki temu wszelkie zmiany związane z fizycznym medium są zamknięte w jednej klasie, a modyfikacja nazw tabel czy poszczególnych kolumn jest banalnie prosta do wprowadzenia. Dodatkowo możemy w DAO zamaskować różnice pomiędzy bazami danych korzystając z warstwy abstrakcji dostępu do bazy, np. AdoDB.

Budujemy własny framework

Nie do końca to rozumiem - czy nie można by było osiągnąć tego samego w klasie modelu? Tzn. "cała logika dostępu do zewnętrznych danych konkretnego typu jest zamknięta w jednej klasie" - w klasie modelu. Rozumiem, że warto implementować warstwę AdoDB (bo zyskujemy większą przenośność kodu - nie obchodzi nas jaki to system bazodanowy - MySQL, PostgreSQL, Oracle, czy jakikolwiek inny), ale czy implementowanie warstwy DAO w frameworku MVC nie jest trochę przerostem formy nad treścią (skoro to co w DAO da się zrobić w modelu)?

Ten post edytował Demoneos 13.12.2011, 10:53:52

[Crozin]

1. Logika biznesowa to ogół zagadnień związanych z szeroko rozumianym przetwarzaniem danych.
2. Nowość, artykuł, autor itp. to obiekty biznesowe / obiekty domeny i jako takie stanowią jedynie część modelu związanego z nowościami, artykułami i autorami.
3. MVC nie oznacza, że dla każdego obiektu biznesowego będziesz mieć po trzy klasy (ArticleModel, ArticleView, ArticleControler itp.). Po pierwsze dla każdego z takich obiektów możesz mieć po kilka klas w każdej z tych warstw (model nie ogranicza się do pobierania danych, widok nie ogranicza się do szablonu strony), po drugie wzorzec ten opisuje ogólną, całościową architekturę aplikacji, nie jej drobne elementy.
4. Możesz mieć przykładowo obiekt biznesowy BankAccount i dla niego kolejno: BankAccount, BankAccountDAO, BankAccountDTO, BankAccountTransferService, BankAccount...Service, BankAccount...Serivce, BankAccount..Repository itd. i dopiero one całościowo tworzą model, a dokładniej model dla konkretnego elementu aplikacji. Dokładnie to samo jest z widokiem.

[Demoneos]

3. MVC nie oznacza, że dla każdego obiektu biznesowego będziesz mieć po trzy klasy (ArticleModel, ArticleView, ArticleControler itp.).

Dla każdego nie, bo np. jeżeli obiekty biznesowe Nowości i Artykuły będą bardzo podobnie działać - np. treść będzie wyświetlana w ten sam sposób i pobierana z bazy danych też w ten sam sposób, z tym wyjątkiem w przypadku Nowości będzie pobieranych np. 10 najnowszych wierszy z tabeli, a w przypadku Artykułów pobieranie będzie np. wg. kategorii, to tutaj rzeczywiście oba te obiekty mogą współdzielić wspólny widok, kontroler i model. Natomiast jeżeli będzie jakiś zupełnie inaczej działający lub mocno rozbudowany obiekt biznesowy - np. Forum, to tutaj już chyba warto zaimplementować go na oddzielnych klasach modela, kontrolera i widoku? Dobrze myślę, czy zupełnie źle?

Po Twoich postach widzę, że jeszcze sporo nauki przede mną Mógłbyś polecić jakąś literaturę o frameworkach MVC?

Ten post edytował Demoneos 14.12.2011, 14:34:28