2012-07-04 16 views
8

Mamy typową aplikację java n-tier i zauważyłem, że nasze warstwy dostępu do danych mają DAO, które są typu FooDAO i FooDAOImpl. Szukałem uzasadnienia potrzeby tych dwóch i oto moja analiza.Potrzebuję oddzielnego interfejsu i imporu dla DAO

  1. W przypadku wielu implementacji dla tego samego interfejsu abstrakcja jest pomocna. Ale biorąc pod uwagę, że już dokonaliśmy wyboru struktury, która ma być zastosowana dla DAOImpl (powiedzmy iBATIS), czy jest to naprawdę wymagane?
  2. Pomoc w pośredniczeniu przez Spring. Z tego, co zbieram, klasy posiadające interfejsy mogą być łatwo proxy (przechodzenie przez ścieżkę JdkProxy) zamiast klas, które nie mają interfejsów (gdzie wybrana jest trasa cglib), a jedna ma podklas klasy, która ma być proxy. Podklasowanie ma swoje problemy, gdy klasa do prokoryzacji jest ostateczna lub nie ma domyślnych konstruktorów - obie są bardzo mało prawdopodobne w warstwie dostępu do danych. Wydajność była czynnikiem, ale z tego, co słyszę, nie jest już powodem do niepokoju.
  3. Pomoc w szyderstwie. Klasy z interfejsami lepiej nadają się do wyśmiewania przez szydercze frameworki. Słyszałem o tym tylko, ale nie widziałem tego w praktyce - tak naprawdę nie mogę na to liczyć, ale może z powodu tych samych czynników, o których wspomniano w punkcie 2 powyżej.

Nie odczuwam rzeczywistej potrzeby posiadania osobnych FooDAO i FooDAOImpl, w których wystarczy zwykła FooDAO. Możesz poprawić którykolwiek z punktów, o których wspomniałem.

Z góry dziękuję!

+1

Chyba że się mylę, nie pytasz tutaj o to pytanie? Korzyści z używania interfejsów z wtryskiem są już określone w twoim "pytaniu" ... – steelshark

+0

Tak, podałeś trzy powody, dla których warto używać interfejsu i implementacji DAO. Wyciągnęłbym przeciwny wniosek do ciebie, a mianowicie, że istnieje potrzeba posiadania interfejsu! –

+0

@ user935439 Pytanie jest w każdym punkcie wypunktowania. Chociaż zasadniczo zgadzamy się co do zalet interfejsów, chciałem zebrać opinie na temat zmniejszenia liczby plików klas, które muszę napisać i zachować, gdy korzyści z interfejsu w takim przypadku nie są w pełni widoczne. Czy wiesz na przykładach, czy kpiny są łatwiejsze, gdy masz do czynienia z interfejsami? Dzięki! – Kilokahn

Odpowiedz

2

Próbowałem # 3 z Mockito i było to w stanie wyśmiewać POJO bez interfejsów. Biorąc pod uwagę argumenty przytoczone przeciwko # 1 i # 2, nie jestem skłonny, aby na razie iść z oddzielnymi DAO i DAOImpl. Możesz dodać inne punkty porównania.

1

widzę czwarty powód:

  • szczegóły implementacji Ukryj

zależności na przykład w zespole, oczekiwany czas życia oprogramowania lub ilość zmian przewidywanych w przyszłości, to się opłaca ukryć jak najwięcej, nawet jeśli istnieje tylko jedna implementacja.

0

Powiedziałbym, że posiadanie interfejsu FooDAO z pojedynczą implementacją FooDAOImpl jest ogólnie anty-wzorem. Prostsze rozwiązanie (brak oddzielnych interfejsów dla DAO) jest o wiele lepszym rozwiązaniem, chyba że masz inny solidny powód - w tym przypadku nie ma to miejsca.

Osobiście chciałbym pójść jeszcze dalej i powiedzieć, że posiadanie DAO wcale nie jest najlepszym wyborem. Wolę jedną klasę elewacji trwałości zaimplementowaną na interfejsie API ORM, takim jak Hibernate lub JPA. Może iBATIS jest za niski na to.