Utrzymanie luźno sprzężonego modelu MVC z DB?

Lubię, aby mój kod był testowalny i zdecydowałem się na strategię Dependency-Injection dla mojego obecnego frameworka MVC, który zdecydowanie okazał się świetnym sposobem na zapewnienie luźno powiązanego kodu, testowalności i modułowości.

Ale ponieważ jestem dalekim od mistrza we wzorcach projektowych, trudno mi znaleźć dobry sposób na utrzymanie moich modeli tak luźno powiązanych z klasami łączników bazy danych, jak to możliwe.

Jak można to zrobić?
Ponieważ nie podałem żadnego kodu fizycznego wraz z tym pytaniem, naprawdę docenię kilka przykładów logiki / kodu lub informacji, które mogłyby skierować mnie w kierunku zrozumienia wyżej opisanego problemu.

Jednym ze sposobów jest zaprojektowanie modeli przed zaprojektowaniem bazy danych. Podczas projektowania modeli nacisk kładziony jest na uchwycenie logiki biznesowej i znaczeń w dziedzinie problemów. Powinno to zostać zarejestrowane w sposób, który ma sens dla firmy, obejmujący więcej niż tylko podmioty i pola danych. Niektóre elementy danych są interpretowane na podstawie innych, niektóre są zależne od innych, itp. Dodatkowo do tego modelu można dodać dowolną podstawową logikę, taką jak wewnętrzna reakcja obiektu, gdy określony element ma określoną wartość.

Jest całkiem prawdopodobne, że skończysz z czymś, co jest w ponad 90% identyczne z tym, w jaki sposób utrwalisz dane. W porządku. Może być całkowicie identyczny bez połączenia.

Zauważ też, że modelowanie domeny we mgle prawdziwej uporczywej ignorancji jest trochę świętym Graalem w projektowaniu oprogramowania. Jeśli możesz to zrobić, fantastycznie. Ale jeśli domena problemowa jest w ogóle znacząca i ma jakąkolwiek złożoność, to dobrze jest od czasu do czasu wycofać się z modelowania domeny, aby sprawdzić poprawność trwałości danych, aby upewnić się, że nie malowałeś się w kąt.

Pamiętaj tylko o rzeczywistych rolach różnych komponentów i zachowaj je oddzielnie podczas ich projektowania. Przy każdej decyzji projektowej zadaj sobie pytanie, czy któraś z tych ról została naruszona:

1. Baza danych - przechowuj dane, zachowaj integralność danych, utrzymuj dane w spoczynku.
2. Modele - zawierają logikę biznesową, modelują domenę problemów, utrzymują dane w ruchu, reagują na zdarzenia na poziomie biznesowym itp.
3. Widoki - Prezentuj dane użytkownikom, wykonuj logikę po stronie użytkownika (podstawowe sprawdzanie poprawności przed przeprowadzeniem prawdziwej weryfikacji w modelach itp.).
4. Kontrolery - Odpowiadaj na zdarzenia użytkownika, przekaż kontrolę modelom, kieruj żądania i odpowiedzi zwrotne.

Chcesz mieć dwie rzeczy.

1. Twoje modele (akcesoria do DBAL i wykonywanie większości logiki aplikacji).

2. Twoje „Modele domeny”, czyli encje danych, reprezentują byty twojego systemu, takie jak użytkownicy, posty, produkty itp.

   class PPI_Model_User {
   
       protected $_conn = null;
   
       function __construct(array $options = array()) {
           if(isset($options['dsnData'])) {
               $this->_conn = new PPI_DataSource_PDO($options['dsnData']);
           }
       }
   
       function getAll() {
           $rows = $this->_connect->query("SELECT .....")->fetchAll();
           $users = array();
           foreach($rows as $row) {
               $users[] = new PPI_Entity_User($row);
           }
           return $users;
       }
   
   }

Kod użytkowania

    $model = new PPI_Model_User(array('dsnData' => $dsnData));
    $users = $model->getAll();
    foreach($users as $user) {
        echo $user->getFirstName();
    }

Oto, jak tworzysz modele domen (Encje) i masz modele MVC wykonujące połączenia z DB i manipulujące danymi.

Jeśli zastanawiasz się, czym jest PPI, przejdź do Google dla „PPI Framework”.

Powodzenia w wyszukiwaniu.

Pozdrawiam, Paul Dragoonis.

Pamiętaj, MVC powstało w smalltalk, który ma automatyczną trwałość dla wszystkich obiektów. Tak więc wzorzec MVC nie zaleca żadnego rozwiązania dla separacji modelu / trwałości.

Preferuję obiekt „Repozytorium”, który wie, jak tworzyć obiekty modelu z bazy danych i przechowywać obiekty modelu w bazie danych. Wtedy Model nie wie nic o wytrwałości. Niektóre działania użytkownika będą musiały uruchomić zapis, więc prawdopodobnie kontroler będzie wiedział o repozytorium. Zwykle używam jakiejś formy wstrzykiwania zależności, aby nie dopuścić do połączenia kontrolera z repozytorium.