Co to jest hibernacja? Podstawa implementacji Hibernate Core
Opublikowany: 2013-04-17
Hibernate to projekt struktury trwałości Java o otwartym kodzie źródłowym. Wykonuj zaawansowane mapowanie relacyjne obiektów i bazy danych zapytań przy użyciu HQL i SQL.
Ogólnie rzecz biorąc, powszechnie używane biblioteki są dobrze zaprojektowane i zaimplementowane i bardzo interesujące jest uczenie się od nich kilku najlepszych praktyk kodowania.
Zajrzyjmy do podstawowej biblioteki hibernacji i odkryjmy niektóre z jej kluczy projektowych.
W tym poście Hibernate Core jest analizowany przez JArchitect , aby zagłębić się w jego projekt i implementację.
Pakiet według funkcji
Package-by-feature używa pakietów do odzwierciedlenia zestawu funkcji. Umieszcza wszystkie elementy związane z pojedynczą funkcją (i tylko tą funkcją) w jednym katalogu/pakietu. Skutkuje to pakietami o wysokiej spójności i wysokiej modułowości oraz minimalnym sprzężeniu między pakietami. Przedmioty, które ściśle ze sobą współpracują, są umieszczane obok siebie.
Hibernate core zawiera wiele pakietów, z których każdy jest powiązany z określoną funkcją hql, sql i innymi.
Sprzęganie
Niskie sprzężenie jest pożądane, ponieważ zmiana w jednym obszarze aplikacji będzie wymagać mniejszej liczby zmian w całej aplikacji. Na dłuższą metę może to zmniejszyć dużo czasu, wysiłku i kosztów związanych z modyfikowaniem i dodawaniem nowych funkcji do aplikacji.
Oto trzy kluczowe korzyści płynące z używania interfejsów:
- Interfejs umożliwia zdefiniowanie kontraktu, który promuje ponowne użycie. Jeśli obiekt implementuje interfejs, to obiekt ten musi być zgodny ze standardem. Obiekt, który używa innego obiektu, nazywany jest konsumentem. Interfejs to umowa między obiektem a jego konsumentem.
- Interfejs zapewnia również poziom abstrakcji, który ułatwia zrozumienie programów. Interfejsy umożliwiają programistom rozpoczęcie rozmowy o ogólnym sposobie zachowania kodu bez konieczności wchodzenia w szczegółowe informacje.
- Interfejs wymusza niskie sprzężenie między komponentami, co ułatwia ochronę konsumenta interfejsu przed wszelkimi zmianami implementacji w klasach implementujących interfejsy.
Poszukajmy wszystkich interfejsów zdefiniowanych przez Hibernate Core, w tym celu używamy CQLinq do odpytywania bazy kodu.
|
1 |
from t in Types where t . IsInterface select t |
Jeśli naszym głównym celem jest wymuszenie niskiego sprzężenia, podczas korzystania z interfejsów pojawia się powszechny błąd, który może zabić użyteczność ich używania. Jest to użycie klas konkretnych zamiast interfejsów. Aby lepiej wyjaśnić ten problem, weźmy następujący przykład:
Klasa A implementuje interfejs IA, który zawiera metodę kalkulatora(), klasa konsumencka C jest zaimplementowana w ten sposób
|
1 2 3 4 5 6 7 8 9 10 11 |
public class C < br > { … . public void calculate ( ) { … . . m_a . calculate ( ) ; … . } A m_a ; } |
Klasa C zamiast odwoływać się do interfejsu IA, odwołuje się do klasy A, w tym przypadku tracimy korzyści z niskiego sprzężenia, a ta implementacja ma dwie główne wady:
- Jeśli zdecydujemy się na zastosowanie innej implementacji IA, musimy zmienić kod klasy C.
- Jeśli do A nieistniejącego w IA dodamy jakieś metody, a C z nich skorzysta, stracimy również korzyści wynikające z używania interfejsów.
C# wprowadził możliwość implementacji interfejsu jawnego do języka, aby zapewnić, że metoda z IA nigdy nie będzie wywoływana z odwołania do konkretnych klas, ale tylko z odwołania do interfejsu. Ta technika jest bardzo przydatna do ochrony programistów przed utratą korzyści z używania interfejsów.
Z JArchitectem możemy sprawdzić tego rodzaju błędy za pomocą CQLinq , chodzi o wyszukanie wszystkich metod z konkretnych klas wykorzystywanych bezpośrednio przez inne metody.
|
1 2 3 4 5 6 7 8 9 |
from m in Methods where m . NbMethodsCallingMe > 0 && m . ParentType . IsClass && ! m . ParentType . IsThirdParty && ! m . ParentType . IsAbstract let interfaces = m . ParentType . InterfacesImplemented from i in interfaces where i . Methods . Where ( a = > a . Name == m . Name && a . ParentType ! = m . ParentType ) . Count ( ) > 0 select new { m , m . ParentType , i } |
Problem ten dotyczy na przykład metody getEntityPersister z SessionFactoryImpl, która implementuje interfejs SessionFactoryImplementor.
Poszukajmy metod wywołujących bezpośrednio SessionFactoryImpl.getEntityPersister.
|
1 2 3 |
from m in Methods where m . IsUsing ( "org.hibernate.internal.SessionFactoryImpl.getEntityPersister(String)" ) select new { m , m . NbBCInstructions } |
Metody takie jak SessionImpl.instantiate wywołują bezpośrednio getEntityPersister, zamiast przekazywać przez interfejs, co psuje korzyści płynące z używania interfejsów. Na szczęście rdzeń hibernacji nie zawiera wielu metod mających ten problem.
Łączenie z zewnętrznymi słoikami
Kiedy używane są zewnętrzne biblioteki, lepiej sprawdzić, czy możemy łatwo zmienić bibliotekę innej firmy na inną bez wpływu na całą aplikację, jest wiele powodów, które mogą nas skłonić do zmiany biblioteki innej firmy.
Druga biblioteka mogłaby:
- Miej więcej funkcji
- Mocniejszy
- Więcej Ochrony
Weźmy przykład antlr lib , który parsował zapytania hql, i wyobraźmy sobie, że powstał inny parser o większej mocy niż antlr, czy możemy łatwo zmienić antlr przez nowy parser?
Aby odpowiedzieć na to pytanie, wyszukajmy, które metody z hibernacji używają go bezpośrednio:
|
1 2 3 |
from m in Methods where m . IsUsing ( "antlr-2.7.7" ) select new { m , m . NbBCInstructions } |
A którzy z nich korzystali pośrednio:
|
1 2 3 4 |
from m in Projects . WithNameNotIn ( "antlr-2.7.7" ) . ChildMethods ( ) let depth0 = m . DepthOfIsUsing ( "antlr-2.7.7" ) where depth0 > 1 orderby depth0 select new { m , depth0 } |
Wiele metod korzysta bezpośrednio z antlr, co sprawia, że rdzeń hibernacji jest z nim silnie powiązany, a zmiana antlr na inny nie jest łatwym zadaniem. Ten fakt nie oznacza, że mamy problem z hibernacją, ale musimy być ostrożni podczas korzystania z biblioteki innej firmy i dobrze sprawdzić, czy biblioteka innej firmy musi być nisko połączona z aplikacją, czy nie.
Spójność
Zasada pojedynczej odpowiedzialności mówi, że klasa powinna mieć jeden i tylko jeden powód do zmiany. Mówi się, że taka klasa jest spójna. Wysoka wartość LCOM generalnie wskazuje na słabo spójną klasę. Istnieje kilka metryk LCOM. LCOM przyjmuje swoje wartości z zakresu [0-1]. LCOMHS (HS oznacza Henderson-Sellers) przyjmuje swoje wartości w zakresie [0-2]. Należy zauważyć, że metryka LCOMHS jest często uważana za bardziej wydajną w wykrywaniu typów niespójnych.
Wartość LCOMHS wyższą niż 1 należy uznać za alarmującą.
Generalnie klasy bardziej zainteresowane spójnością są klasy posiadające wiele metod i pól.
Poszukajmy typów posiadających wiele metod i pól.
|
1 2 3 4 |
from t in Types where ( t . Methods . Count ( ) > 40 | | t . Fields . Count ( ) > 40 ) && t . IsClass orderby t . Methods . Count ( ) descending select new { t , t . InstanceMethods , t . Fields , t . LCOMHS } |
To zapytanie dotyczy tylko kilku typów, a dla wszystkich LCOMHS wynosi mniej niż 1.
Korzystanie z adnotacji
Programowanie oparte na adnotacjach uwalnia programistów Javy od kłopotliwej konfiguracji. I daj nam potężną funkcję, aby uwolnić kod źródłowy od kodu standardowego. Wynikowy kod jest również mniej podatny na błędy.
Poszukajmy wszystkich adnotacji zdefiniowanych przez rdzeń hibernacji.
|
1 |
from t in Types where t . IsAnnotationClass && ! t . IsThirdParty select t |
Zdefiniowanych jest wiele adnotacji, co sprawia, że hibernacja jest łatwa w użyciu przez programistów i unika się problemów związanych z plikami konfiguracyjnymi.
Wniosek
Hibernate Core jest dobrym przykładem projektów open source, z których można się uczyć, nie wahaj się zajrzeć do środka.