Kodowanie czas zacząć – first commit

Git został wstępnie poznany, skonfigurowany, zdalne repozytorium dodane, mogę więc pochwalić się wynikami mojej dotychczasowej pracy nad aplikacją. Trochę czasu minęło od wystartowania DSP, niektórzy mogą powiedzieć, że to co Ci przedstawiam, to w sumie nic nie robiący zlepek kodu. Moim zdaniem jest jednak inaczej.

Obecny kod przedstawia podstawowe klasy. Pakiet com.main.model zawiera zamodelowane klasy employee, customer i rodzaje wymienionych, odpowiednio EmployeeType i CustomerType. Każda z nich inicjuje swoje pola, od razu mapuje je z tabelą w bazie danych i odpowiednimi kolumnami:

@Entity
@Table(name="employee")
public class Employee implements Serializable{
	@Id
	@Column(name = "empId", nullable = false)
	private long id;
	@Column(name = "first_name", nullable = false)
	private String firstName;
	@Column(name = "last_name", nullable = false)
	private String lastName;
	@Column(name = "position")
	private String position;
	@Column(name = "email")
	private String email;
	@Column(name = "telephone")
	private String telephone;
    @JoinColumn(name = "empTypeId_fk") @ManyToOne(fetch = FetchType.EAGER)
	private EmployeeType empType;
	public Employee(){};

}

Tutaj muszę jeszcze się zastanowić, zebrać opinie, w kwestii mapowania bezpośrednio w klasach – czy jest ono lepsze, od mapowania w oddzielnym pliku xml – wydaje mi się, że to drugie będzie lepszym rozwiązaniem. Ale na to przyjdzie jeszcze czas. Także zdaję sobie sprawę, że FetchType.EAGER nie jest najlepszym rozwiązaniem jeśli chodzi o wydajność aplikacji, ponieważ zbiera on kolekcję danych zaraz po inincjalizacji sesji. LAZY zbiera kolekcję dopiero przy jego bezpośrednim wywołaniu. Ten pierwszy może żżerać pamięć w szybkim tempie. Dlatego zostawiam to jako TODO.

Za manipulację rekordami odpowiadają klasy DAO w pakiecie com.main.dao. Tam znajdziesz interfejsy i implementacje. Podstawowe metody jakie na tą chwilę zaimplementowalem w interfejsach to (np. dla adresu):

	Address findAddress(long id);
	List<Address> getAllAddresses();
	void addAddress(Address address);
	void updateAddress(Address address);
	void deleteAddress(Address address);

FindAddress wyszukuje jeden adres na podstawie przekazanego ID, zwraca typ Address. getAllAddresses zwraca listę typu Address z wszystkimi rekordami z tabeli – SELECT * FROM Address.
Kolejne trzy metody odpowiadają za manipulację danymi add, update i deleteAddress. Do metody przekazywany jest Address.

Manipulację na danych wykonałem przy użyciu frameworka Hibernate i obiektu SessionFactory. Obiekt pobiera aktualną sesję i wykonuje daną operację. Hibernate w całości zwalnia z programowania zapytań do bazy. Jedyne co jest potrzebne, to znajomość podstawowych zasad i zależności w relacyjnych bazach danych, głownie wymagana do odpowiedniego zmapowania tabel i kolumn, ustawienia odpowiedniego joinowania między tabelami. Hibernate musi to wiedzieć, aby przygotować odpowiednie zapytania.

@Override
public void addAddress(Address address) {
    sessionFactory.getCurrentSession().persist(address);
};

Oprócz DAO zaimplementowałem SERWISY do obsługi klienta i pracownika. Serwisy na tą chwilę implementują te same metody co DAO, jednak w przyszłości będę mógł w nich umieścić odwołania do kilku DAO. Np w serwisie Customer będę mógł przypisać Contact do Customer’a. Serwis różni się od DAO tym, że odwołuje się do obiektu DAO, nie wie jak DAO sobie radzi z manipulacją danymi. Separacja kolejny raz 🙂

Klasa główna to na tą chwilę klasa sprawdzająca działanie serwisów, służyła mi do pobierania rekordów, wyświetlania, dodawania. Tworzy nowy context w oparciu o plik apllicationContext.xml, gdzie zdefiniowane są Beany takie jak dataSource – baza danych, sessionFactory. Wywołanie contextu, serwisu oraz krótkie wprowadzenie nowego obiektu do bazy poniżej:

ConfigurableApplicationContext context = 
          new ClassPathXmlApplicationContext("applicationContext.xml");
EmployeeTypeService empTypeService = (EmployeeTypeService) 
          context.getBean("EmployeeTypeService");

  //utworzenie obiektu employeeType
EmployeeType empType = new EmployeeType(); 
empType.setName("Prezes");

  //dodanie nowego obiektu do bazy
empTypeService.addEmployeeType(empType); 

  //wyciągnięcie z bazy wszystkich employeeType
List<EmployeeType> empTypeList = empTypeService.getAllEmployeeTypes(); 
  //pętla wyświetlająca szczeóly obiektów employeeType z listy
for (EmployeeType et : empTypeList) { 
  System.out.println(" Name: "+et.toString());
}

Jak widzisz na powyższym przykładzie, operuję jedynie na Modelu, po to żeby zdobyć instancję danego obiektu, czy to będzie Customer, czy Employee, czy EmployeeType. Wszelkie operacje na obiektach dokonuję przez serwisy. Wywołuję instancję serwisu i mogę odwoływać się do jego metod. Jak wspomniałem wceśniej, w przyszłości serwisy będą mogły implementować kilka instancji klasy DAO – czyli będą zdolne manipulować kilkoma obiektami z pakietu Model. Jest to spora zaleta. Na początku nie byłem przekonany do serwisów, mogłem przecież odwołać się bezpośrednio do DAO w klasie głównej. Jednak ta idea jest lepsza. DAO powiązane jest z MODELem w relacji 1 o 1, a serwis może wiązać się z kilkoma DAO – czyli 1 do n. Docelowo ułatwi i przyspieszy to pracę nad projektem.

Ok. Garść informacji o projekcie przekazana. Trzeba pracować dalej. Jakie plany? Myślę, że trzeba zając się obsługą wyjątków, pomyśleć o testach, zacząć powoli budować GUI (Graphical User Interface) – tutaj prawdopodobnie pójdzie na warsztat JavaFx, która jest teraz na topie, wypierając z rynku nie wspieranego już Swinga. See you soon.

Jeśli masz jakiekolwiek uwagi, sugestie, opinie (zwłaszcza te negatywne mile widziane) nt kodu, aplikacji, artykułu, pisz śmiało 🙂

Dodaj komentarz

Twój adres email nie zostanie opublikowany. Pola, których wypełnienie jest wymagane, są oznaczone symbolem *