Closed dawidkomorowski closed 8 years ago
1) Czyli robimy to na ORMie i szablony klas wyklikujemy w IDE? 2) Repository nie znam, ale jeżeli łatwo zaimportować to do projektu, to wygląda na to, że idzie ogarnąć je w pół godziny, może być. Hibernate ostatecznie odrzucamy?
@ 1 Nie widzę za bardzo sensu wyklikiwać w IDE czegokolwiek, przy tak prostych klasach. Zwykle razem z ORM stosuje się podejście tzw. "code first". Jako że nasza aplikacja nie będzie mieć jakiegokolwiek życia, to problemy upgrade scriptów nie muszą być nawet rozważane, a zatem spokojnie można oprzeć się na "auto-magii" przy mapowaniu.
@ 2 Repository to tylko wzorzec projektowy odseparowania BLL (Business Logic Layer) od DAL (Data Access Layer). Co do samej technologii dostępu do bazy danych i ewentualnego mapowania, Hibernate jak dla mnie może być - w takim małym projekcie, łatwo daje się okiełznać i nie trzeba walczyć z wydajnością czy niuansami ręcznej manipulacji schematem bazy. Oczywiście technologii jest wiele i potencjalna osoba, która będzie ten fragment implementować ma pełną dowolność - byle dostarczyć abstrakcyjny interfejs dostępu do danych, tak że nikt inny nie musi znać samej technologii. Jeżeli mi przyjdzie to implementować, to zważywszy na Javę wybrałbym pewnie właśnie Hibernate.
@invader92 Zpushowałem najnowsze zmiany (jeszcze troszkę do dokończenia) tak abyś miał obraz w jakim kierunku zacząłem zmierzać.
Należy zaprojektować i zaimplementować "proof of concept" mechanizmu dostępu do danych. Preferowana baza to SQLite (motywacja: prosty driver bez zależności). Nie narzucane są żadne mechanizmy obsługi bazy danych byle nad nimi była stosowna abstrakcja. Pod spodem może być ORM, SQL, lub inne wzorce/mechanizmy, na wierzchu DAO lub Repository. Zastanowić się nad potrzebą i problemami transakcji.