Co to jest DCI i jak może pasować do szyn?

Dla ludzi, którzy zastanawiają się, co oznacza DCI..

DCI oznacza Data Context Interaction

Sercem DCI są narzędzia poznawcze, które dostarcza programiście. Nie jestem pewien, czy widziałeś wszystkie wspaniałe wykłady Jamesa Copliena/Trygve Reenskauga , ale postaram się opisać sedno tego dla każdego, kto jest nowy w pojęciach. Chodzi o przeniesienie zachowania systemu z obiektów domeny interakcji systemów (jednostki danych, lub co system jest), a do obiektów zachowania (co System robi) jako obywatele pierwszej klasy, które pośredniczą w współpracy między obiektami przez wprowadzenie ich funkcjonalności w kontekście przypadków użycia just-In-time.

Myśl BDD. Kodujemy zachowanie nie w wielu obiektach, takich jak cząstki funkcjonalności rozłożone na wszystkich naszych obiektach danych, które są wysoce sprzężone z warstwą trwałości, ale w spójnych obiektach, które istnieją wyłącznie dla przypadku użycia(historia), i które wstrzykują możliwości i koordynują interakcje tych głupich obiektów danych. Jak zwykłe warstwy fizycznej architektury, powoli zmieniające się dane obiekty nie są ładowane z szybko zmieniającą się implementacją funkcji, którą noszą cały czas. Zamiast tego, Ruby zapewnia nam możliwość łatwego wprowadzania zachowania do obiektów w czasie wykonywania, gdy / jeśli jest to potrzebne tylko w kontekście przypadku użycia.

Jako przykład w ROR, jeśli masz akcję kontrolera zaangażowaną w przypadek użycia, w którym istnieje macierz prawdopodobieństwa zdarzenia, w której większość wpisów może być wyzwalana tylko w niewielkim odsetku żądań, to utworzenie sieci z nadęte zachowanie-ciężkie obiekty z wiedzą, aby wykonać każde zdarzenie dla każdego możliwego przypadku użycia danych jest niepotrzebne. Ponadto, brak konieczności przekopywania się przez pliki 18 w edytorze tekstu, aby zrozumieć, jak działa ta interakcja, a także posiadanie całej logiki czysto abstrakcyjnej do wzorców w interfejsie dostarczanym przez obiekt context jest również zdecydowanym plusem.

Jeśli chodzi o twoje pytanie o "inną" warstwę abstrakcji między kontrolerami a Modelami w railach, nie jestem pewien, które Inne do którego się odnosisz. Niezależnie Od Tego, Tak. Oczywiście. Nie ma sprawy. wzorce projektowe i solidne zasady Uncle Bobs' są ogólnie przyjętymi najlepszymi praktykami w projektowaniu OO. Obie te kwestie zdecydowanie zachęcają do luźnego powiązania abstrakcji między polityką a wdrażaniem. Oba pomagają uniknąć katostroficznych wysypisk mózgów o rozmiarach niszczących Imperium Rzymskie, ponieważ zapewniają wspólne ramy, które wszyscy rozumieją. DCI, dla mnie, zapewnia ten sam rodzaj poznawczych framework, ale dla ułatwienia zrozumienia systemu i skutecznego radzenia sobie z nim, i to jest Święty Graal dla każdego projektanta zorientowanego obiektowo.

Jest książka (obecnie w toku) o używaniu DCI w Ruby/Rails: Clean Ruby. Gorąco polecam umieszczenie się na liście powiadomień-przeczytałem fragmenty tej książki i wygląda naprawdę dobrze.

DCI zyskuje akceptację w świecie Rails - w ciągu ostatnich 3 miesięcy pojawiło się na nim wiele ciekawych wpisów na blogu.