Czy związek między Usługą a DAO powinien być jeden do jednego lub jeden do wielu?

Question

Kod, który wywołał to pytanie, to usługa w bazie kodu mojej firmy, która zawierała cztery różne DAO. Niewiele o tym myślałem, dopóki nie zobaczyłem, że ta Usługa została połączona z metodami, które należały do ​​zupełnie innej Usługi. Powodem stworzenia tych nieuzasadnionych metod w ramach tej Usługi było po prostu to, że potrzebne DAO były prywatnymi członkami tej klasy Usług.

Czy to jest błąd programisty, czy też w większości przypadków jest ono niewłaściwe w przypadku posiadania więcej niż jednego DAO na klasę usług?

Uwaga: Zauważyłem, że uzasadnione jest posiadanie więcej niż jednego DAO na klasę usługi, o ile wszystkie są zawarte w tej samej bazie danych. Ale posiadanie DAO z wielu baz danych wygląda na to, że może powodować problemy.

Answer 1

Nie widzę niczego złego w sytuacji, gdy istnieje wiele DAO na klasę usług. Kiedy wiele lat temu zacząłem tworzyć strony internetowe, miałem jedną usługę jedną DAO, ponieważ wydawało się to najbardziej logicznym i najprostszym podejściem. Następnie zacząłem dostrzegać problemy, w których istnieją podobne API wśród DAO obsługujących różne usługi. Tak więc, moim "niedojrzałym" rozwiązaniem było promowanie tych wspólnych API dla niektórych nadrzędnych DAO, które zostały odziedziczone przez te DAO. Kiedy projekt rośnie, doszło do punktu, w którym dziedziczenie nie ma już sensu, ponieważ mam sytuacje, w których 80% dzieci DAO potrzebuje tego API, ale 20% nie, ale wciąż dziedziczą z tego samego rodzica DAO, ponieważ udostępniają inne podobne interfejsy API. Widzisz problem tutaj? Mam na myśli, że w Javie możesz dziedziczyć tylko z jednego rodzica, więc skończyłem na wypychaniu API, które "może" być użyte przez "większość" DAO w macierzystym DAO, co całkowicie narusza zasadę dziedziczenia.

W tej chwili wszystkie moje zajęcia DAO mają określone obowiązki/zadania. Jest w porządku, aby DAO mógł wywołać inne DAO (na przykład LoggingDAO jest używane przez większość DAO do rejestrowania działań użytkowników). W ten sposób zamiast jednego DAO obsługującego określoną usługę, DAO udostępnia listę operacji, które mogą przynieść korzyści tej usłudze. Usługa będzie "wykorzystywać" dowolne DAO, które wykona to zadanie.

Mam nadzieję, że to wyjaśnienie pomaga.

Answer 2

Jeden do wielu jest w porządku, o ile ma sens rozbicie DAO.

Kilka powodów mogę myśleć, gdzie ma to sens, aby podzielić DAO:

• różnych baz danych. Jeśli masz do czynienia z kontem i bazą danych sprzedaży, możesz chcieć oddzielić DAO od SalesDAO i AccountingDAO. Ułatwi to utrzymanie.
• Ponowne użycie. Możesz mieć kilka metod, które mogą być ponownie wykorzystane w kilku miejscach, a ich rozdzielenie umożliwi lepsze ponowne wykorzystanie.

Answer 3

W jednej firmie, w której pracowałem, miały ładny design, w którym usługa nazywała się kontrolerem, a kontroler mógł zadzwonić do innej warstwy, której nie pamiętam, ale wtedy zadzwoniłbym do DAO.

Mają więc poziom dostępu, który może wywoływać wiele DAO, w celu wykonania funkcji wyższego rzędu, więc jeśli chcesz wykonać zamówienie, może wymagać wywołania wielu tabel, a może kilku systemów, więc kontroler nazwałby metodę doOrder.

Jest to przyjemny projekt, ponieważ zachowuje dobrą separację i ułatwia testowanie jednostek, ponieważ można przetestować każdą warstwę.

Jeśli Twoja usługa może wywoływać wiele DAO, wtedy testowanie jednostek może być trudniejsze, ponieważ utrudnisz obsługę.

Podczas projektowania warstw należy sprawdzić, czy tworzenie nowych warstw ma sens, aby uprościć projekty, co może wykryć błędy lub zapobiec błędom.

UPDATE:

Brakujące warstwa była koordynatorem, oraz zasady, że każdy koordynator były rozpatrywane jednego DAO i mógł robić żadnych przekształceń, które były potrzebne, ale logika biznesowa była w kontrolerze. Tak więc koordynator może rozmawiać z każdym innym koordynatorem, aby uzyskać informacje, a ci koordynatorzy pójdą do DAO.

Answer 4

http://java.sun.com/blueprints/corej2eepatterns/Patterns/DataAccessObject.html

Kwota na DAO po prostu zależy od źródeł leżących u!