Cytat
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.
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)?
