Orientacja obiektowa jest szczególnie cenna, ponieważ powstają tego rodzaju scenariusze i daje narzędzia do racjonalnego projektowania abstrakcji, które pozwalają na zawarcie złożoności.
Prawdziwe pytanie brzmi: gdzie ujmujesz tę złożoność?
Pozwólcie, że cofnę się na chwilę i porozmawiam o tym, o której „złożoności” mówię tutaj. Twój problem (jak rozumiem; popraw mnie, jeśli się mylę) to model trwałości, który nie jest efektywnie użytecznym modelem do zadań, które musisz wykonać z danymi. Może być skuteczny i użyteczny do innych zadań, ale nie do twoich zadań.
Co więc robimy, gdy mamy dane, które nie przedstawiają dobrego modelu dla naszych środków?
Tłumaczyć. To jedyne, co możesz zrobić. To tłumaczenie jest „złożonością”, o której mowa powyżej. Teraz, gdy akceptujemy zamiar przetłumaczenia modelu, musimy zdecydować o kilku czynnikach.
Czy musimy tłumaczyć oba kierunki? Czy oba kierunki będą tłumaczone tak samo, jak w:
(Tbl A, Tbl B) -> Obj X (czytaj)
Obj X -> (Tbl A, Tbl B) (zapis)
czy też czynności wstawiania / aktualizacji / usuwania reprezentują inny typ obiektu, tak że odczytujesz dane jako Obj X, ale dane są wstawiane / aktualizowane z Obj Y? Który z tych dwóch sposobów chcesz przejść, lub jeśli nie jest możliwa aktualizacja / wstawianie / usuwanie, to ważne czynniki, w których chcesz umieścić tłumaczenie.
Gdzie tłumaczysz
Powrót do pierwszego stwierdzenia, które wypowiedziałem w tej odpowiedzi; OO pozwala ci na hermetyzację złożoności, a to, o czym tu mówię, to fakt, że nie tylko powinieneś, ale musisz hermetyzować tę złożoność, jeśli chcesz mieć pewność, że nie wycieknie ona i nie dostanie się do całego twojego kodu. Jednocześnie ważne jest, aby zdać sobie sprawę, że nie możesz mieć idealnej abstrakcji, więc martw się o to bardziej niż o bardzo skuteczną i użyteczną.
Znowu teraz; Twoim problemem jest: gdzie stawiasz tę złożoność? Masz wybór.
Możesz to zrobić w bazie danych za pomocą procedur przechowywanych. Ma to tę wadę, że często nie gra zbyt dobrze z ORM, ale nie zawsze tak jest. Procedury przechowywane zapewniają pewne korzyści, w tym często wydajność. Procedury przechowywane mogą jednak wymagać wielu czynności konserwacyjnych, ale to do Ciebie należy przeanalizowanie konkretnego scenariusza i stwierdzenie, czy konserwacja będzie większa czy mniejsza niż inne opcje. Ja osobiście mam duże umiejętności w zakresie procedur przechowywanych i jako taki fakt dostępnych talentów zmniejsza koszty ogólne; nigdy nie lekceważ wartości podejmowania decyzji na podstawie tego, co wiesz. Czasami rozwiązanie nieoptymalne może być bardziej optymalne niż prawidłowe rozwiązanie, ponieważ Ty lub Twój zespół wiesz, jak je stworzyć i utrzymywać lepiej niż rozwiązanie optymalne.
Inną opcją w bazie danych są widoki. W zależności od serwera bazy danych mogą one być wysoce optymalne lub nieoptymalne, a nawet w ogóle nieskuteczne, jedną z wad mogą być czasy zapytań w zależności od opcji indeksowania dostępnych w bazie danych. Widoki stają się jeszcze lepszym wyborem, jeśli nigdy nie musisz dokonywać żadnych modyfikacji danych (wstawianie / aktualizowanie / usuwanie).
Przechodząc obok bazy danych masz stary tryb gotowości do korzystania ze wzorca repozytorium. To sprawdzone podejście może być bardzo skuteczne. Wady zwykle obejmują płytę kotłową, ale dobrze przemyślane repozytoria mogą tego uniknąć, a nawet gdy skutkują niefortunną ilością płyty kotłowej, repozytorium jest zwykle prostym kodem, który jest łatwy do zrozumienia i utrzymania, a także prezentuje dobre API /abstrakcja. Również repozytoria mogą mieć dobrą testowalność jednostkową, którą tracisz z opcjami w bazie danych.
Istnieją narzędzia, takie jak auto-mapper , które mogą sprawić, że użycie ORM będzie możliwe, gdy będą mogły dokonać translacji między modelem bazy danych z orm na użyteczne modele, ale niektóre z tych narzędzi mogą być trudne do utrzymania / zrozumienia bardziej przypominającego magię; chociaż tworzą minimalny narzut kodu, co skutkuje mniejszym nakładem prac konserwacyjnych, gdy jest dobrze zrozumiany.
Następnie przechodzisz coraz dalej od bazy danych , co oznacza, że pojawi się większa ilość kodu, który poradzi sobie z nieprzetłumaczonym modelem trwałości, który będzie naprawdę nieprzyjemny. W tych scenariuszach mówisz o umieszczeniu warstwy tłumaczenia w interfejsie użytkownika, co brzmi jak teraz. Jest to ogólnie bardzo zły pomysł i z czasem strasznie rozpada się.
Teraz zacznijmy mówić szalone .
Nie Objectjest to jedyna abstrakcja, która istnieje na końcu. Przez wiele lat rozwinęła się głębia abstrakcji, że informatyka była badana, a nawet wcześniej z matematyki. Jeśli chcemy zacząć być kreatywni, zacznijmy mówić o znanych dostępnych abstrakcjach, które zostały zbadane.
Jest model aktora.Jest to interesujące podejście, ponieważ mówi, że wszystko, co robisz, to wysyłanie wiadomości do innego kodu, który skutecznie deleguje całą pracę do tego innego kodu, co jest bardzo skuteczne w obudowaniu złożoności z dala od całego kodu. Może to działać, o ile wyślesz do aktora wiadomość z informacją: „Potrzebuję Obj X wysłanego do Y”, a ty masz pojemnik oczekujący na odpowiedź w lokalizacji Y, która następnie przetwarza Obj X. Możesz nawet wysłać wiadomość z instrukcją „Potrzebuję Obj X i obliczeń Y, Z gotowe”, a potem nawet nie trzeba czekać; tłumaczenie występuje po drugiej stronie tego komunikatu i możesz przejść dalej, jeśli nie potrzebujesz odczytać jego wyniku. Może to być niewielkie nadużycie modelu aktora do twoich celów, ale wszystko zależy;
Kolejną granicą enkapsulacji są granice procesu. Można je wykorzystać do bardzo skutecznego segregowania złożoności. Możesz utworzyć kod tłumaczenia jako usługę internetową, w której komunikacja jest prosta HTTP, używając SOAP, REST lub jeśli naprawdę chcesz mieć własny protokół (nie sugerowany). STOMP nie jest wcale złym nowszym protokołem. Lub skorzystaj z normalnej usługi demona z publicznie publikowanym potokiem pamięci w systemie, aby ponownie bardzo szybko się komunikować, używając dowolnego wybranego protokołu. Ma to naprawdę całkiem dobre zalety:
- Możesz mieć uruchomionych wiele procesów, które tłumaczą jednocześnie starszą i nowszą wersję, umożliwiając aktualizację usługi tłumaczeniowej w celu opublikowania modelu obiektowego V2, a następnie osobno w późniejszym momencie zaktualizuj konsumujący kod do pracy z nowym obiektem Model.
- Możesz robić ciekawe rzeczy, takie jak przypinanie procesu do rdzenia w celu zwiększenia wydajności, zyskujesz również bezpieczeństwo w tym podejściu, czyniąc ten jedyny proces działający z uprawnieniami bezpieczeństwa, aby dotknąć tych danych.
- Otrzymasz bardzo silną granicę, gdy mówisz o granicach procesu, które pozostaną stałe, zapewniając minimalny wyciek twojej abstrakcji przez długi czas, ponieważ pisanie kodu w przestrzeni tłumaczenia nie będzie mogło zostać wywołane poza przestrzenią tłumaczenia, ponieważ one nie będzie współużytkować zakresu procesu, zapewniając stały zestaw scenariuszy użycia według umowy.
- Możliwość asynchronicznych / nieblokujących aktualizacji jest prostsza.
Wady to oczywiście więcej czynności konserwacyjnych niż jest to zwykle konieczne, narzut komunikacji wpływa na wydajność i konserwację.
Istnieje wiele różnych sposobów na zawarcie złożoności, które mogą pozwolić na umieszczenie tej złożoności w coraz bardziej dziwnych i ciekawych miejscach w twoim systemie. Używając form funkcji wyższego rzędu (często sfałszowanych przy użyciu wzorca strategii lub różnych innych dziwnych form wzorców obiektów), możesz zrobić kilka bardzo interesujących rzeczy.
Zgadza się, zacznijmy mówić o monadzie. Możesz utworzyć tę warstwę tłumaczenia w bardzo niezależny sposób, stosując małe, specyficzne funkcje, które wykonują niezbędne tłumaczenia niezależne, ale ukrywając wszystkie te funkcje tłumaczenia, są niewidoczne, więc są one trudno dostępne dla kodu zewnętrznego. Ma to tę zaletę, że zmniejsza na nich poleganie, umożliwiając łatwą zmianę bez wpływu na kod zewnętrzny. Następnie tworzysz klasę, która akceptuje funkcje wyższego rzędu (funkcje anonimowe, funkcje lambda, obiekty strategii, jednak musisz je nadać strukturę), które działają na dowolnym ładnym obiekcie typu OO. Następnie pozwalasz kodowi źródłowemu, który akceptuje te funkcje, wykonać dosłowne wykonanie przy użyciu odpowiednich metod tłumaczenia.
Tworzy to granicę, w której całe tłumaczenie istnieje nie tylko po drugiej stronie granicy , z dala od całego kodu; jest używany tylko po tej stronie, pozwalając reszcie kodu nawet nie wiedzieć o nim nic poza miejscem, w którym znajduje się punkt wejścia dla tej granicy.
Ok, tak, to naprawdę mówi szalone, ale kto wie; możesz być po prostu taki szalony (poważnie, nie podejmuj monad z oceną szaleństwa poniżej 88%, istnieje realne ryzyko obrażeń ciała).