Baza danych - warstwa dostępu

[Asmodai]

Witajcie,

Jakiś czas temu w osobnym wątku był poruszany temat bazy danych ale z
racji tego że nie było dospecyfikowanych wymagań dyskusja umarła.
Powoli będziemy siadać do implementacji naszych modułów i trzeba
ustalić z jakiego sposobu dostępu będziemy korzystać.
Osobiście wydaje mi się że do naszego projektu idealne będzie JPA -
odetnie nas od bazy danych ale nie nałoży na nas jako osoby uczące się
tak dużego obciążenia terminami/mechanizmami jakie są w Hibernate. I
nie spowodują takiej sieczki w kodzie jaka może być od stosowania
JDBC :).
Odnośnie samej bazy danych z racji że nie jest to projekt który będzie
wymagał tak skomplikowanych mechanizmów jakie posiada PostgreSQL,
zyskamy na szybkości używając MySQL (idealnie nadaje się do średnich
stron).
Ale jeśli ktoś widzi coś ciekawego do czego w tym projekcie moglibyśmy
użyć PG to jestem bardzo za.

Tak, to jest temat do konstruktywnego flame-war.

Pozdrawiam

[Robert Sajdok]

2008/8/21 Asmodai <asm...@2mind.pl>

Jeśli dobrze zrozumiałem, to według ciebie JPA jest mniej skomplikowany od Hibernate, czy tak? Jeśli tak to ja jestem za JPA. Co do bazy to większość była za MySQL, na google code pojawiła się baza Apache Derby. Nie znam jej nie wiem czy się sprawdzi w środowisku produkcyjnym.


--
Robert Sajdok (Ris)

[Robert Sajdok]

2008/8/22 Robert Sajdok <r...@onet.pl>

Chyba popełniliśmy drobny błąd, Hibernate nie jest substytutem JPA. Teraz jest kwestia czego użyć przy JPA, czy Hibernate, czy TopLink lub coś innego, może ktoś ma większą wiedzę i się wypowie ja idę dalej czytać.


--
Robert Sajdok (Ris)

[Jacek Laskowski]

2008/9/15 Robert Sajdok <r...@onet.pl>:

> Chyba popełniliśmy drobny błąd, Hibernate nie jest substytutem JPA. Teraz
> jest kwestia czego użyć przy JPA, czy Hibernate, czy TopLink lub coś innego,
> może ktoś ma większą wiedzę i się wypowie ja idę dalej czytać.

Nie ma znaczenia. JPA jest "przykrywką" dla dostawców JPA jakimi mogą
być Hibernate EntityManager (aka Hibernate JPA), Toplink (obecnie
EclipseLink) lub Apache OpenJPA (komercyjnie Kodo). Przykład użycia
wybranego za pomocą profilu w mavenie, np. Nauka Java Persistence z
Apache Maven 2 i dostawcami JPA: OpenJPA, Hibernate i TopLink [1]

Jacek

[1] http://www.jaceklaskowski.pl/w/index.php?title=Nauka_Java_Persistence_z_Apache_Maven_2_i_dostawcami_JPA:_OpenJPA%2C_Hibernate_i_TopLink

--
Jacek Laskowski
Notatnik Projektanta Java EE - http://www.JacekLaskowski.pl

[Robert Sajdok]

2008/9/15 Jacek Laskowski <ja...@laskowski.net.pl>

2008/9/15 Robert Sajdok <r...@onet.pl>:

> Chyba popełniliśmy drobny błąd, Hibernate nie jest substytutem JPA. Teraz
> jest kwestia czego użyć przy JPA, czy Hibernate, czy TopLink lub coś innego,
> może ktoś ma większą wiedzę i się wypowie ja idę dalej czytać.

Nie ma znaczenia. JPA jest "przykrywką" dla dostawców JPA jakimi mogą
być Hibernate EntityManager (aka Hibernate JPA), Toplink (obecnie
EclipseLink) lub Apache OpenJPA (komercyjnie Kodo). Przykład użycia
wybranego za pomocą profilu w mavenie, np. Nauka Java Persistence z
Apache Maven 2 i dostawcami JPA: OpenJPA, Hibernate i TopLink [1]

Tak, wiem, pytam, co wybrać czy Hibernate czy Toplink, czy coś innego? Masz doświadczenie to możesz coś wskazać?

--
Robert Sajdok (Ris)

[Jacek Laskowski]

2008/9/15 Robert Sajdok <r...@onet.pl>:

> Tak, wiem, pytam, co wybrać czy Hibernate czy Toplink, czy coś innego? Masz
> doświadczenie to możesz coś wskazać?

To jest detal projektowy, ale skoro nalegasz zacznij(my) od
EclipseLink, aby nie było pokus wdrażania konstrukcji hibernate'owych.
Najlepiej jednak stworzyć dwa profile z jednym domyślnym.

Jacek

[morisil]

On Sep 15, 10:26 pm, "Jacek Laskowski" <ja...@laskowski.net.pl> wrote:
> JPA jest "przykrywką" dla dostawców JPA jakimi mogą
> być Hibernate EntityManager (aka Hibernate JPA), Toplink (obecnie
> EclipseLink) lub Apache OpenJPA (komercyjnie Kodo). Przykład użycia
> wybranego za pomocą profilu w mavenie, np. Nauka Java Persistence z
> Apache Maven 2 i dostawcami JPA: OpenJPA, Hibernate i TopLink [1]

> ...
> [1]http://www.jaceklaskowski.pl/w/index.php?title=Nauka_Java_Persistence...

Rzuciłem okiem na tę stronę. Bardzo fajny pomysł z profilami mavena.
Wydaje mi się że można całość usprawnić jeszcze odrobinę - może
spróbujecie w tym projekcie.

1. osobny jar/pom.xml dla entities.

2. Automatyczne rozpoznawanie entities:

<?xml version="1.0" encoding="UTF-8"?>
<persistence version="1.0" xmlns="http://java.sun.com/xml/ns/
persistence" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation=
"http://java.sun.com/xml/ns/persistence http://java.sun.com/xml/ns/persistence/persistence_1_0.xsd">
<persistence-unit name="FooBar" transaction-type="RESOURCE_LOCAL">
<exclude-unlisted-classes>false</exclude-unlisted-classes>
</persistence-unit>
</persistence>

Nie wiem po prawdzie jak to bangla z Hibernate, czy OpenJPA, ale z
EclipseLink wyśmienicie. :) OpenJPA wywodzi się z Kodo (kupione przez
BEA), EclipseLink z TopLink Oracle'a, a Oracle kupił przecie BEA.
Wydaje mi się że to wróży dobrą przyszłość EclipseLinkowi, który ma
się stać Reference Implementation JPA 2.0.

3. Jeden persistence.xml dla wszystkich providerów JPA o ile się da. W
takim przypadku budujemy jednego jara z entities z takim
persistence.xml jak powyżej, a kontener dostarcza odpowiednio
ustawionej implementacji providera. W Twoim przykładzie properties
providera ustawione są w persistence.xml - w przypadku nie stosowania
kontenera wystaczy gdzieś przy inicjalizacji aplikacji coś takiego:

<code>
Properties properties = new Properties();
props.load(in);
EntityManagerFactory emf =
Persistence.createEntityManagerFactory("FooBar", props);
EntityManager em = emf.createEntityManager();
em.close();
</code>

Można przetrzymać EntityManagerFactory i wstrzykiwać potem jako
zależność, albo zrobić:

Persistence.createEntityManagerFactory("FooBar");

To co wpada wtedy w profil mavena to właśnie ten plik properties.
Można go trzymać np. jako resource dorzucane do classpath, czy w
dowolnym innym miejscu przeznaczonym do przetrzymywania konfiguracji
aplikacji.

--
"Meaning is differential not referential"

kazik 'morisil' pogoda
http://www.xemantic.com/ http://blog.xemantic.com/

[Jacek Laskowski]

2008/9/16 morisil <hsh...@gmail.com>:

> 3. Jeden persistence.xml dla wszystkich providerów JPA o ile się da.

Da się. Nierozpoznawana konfiguracja w postaci properties jest
ignorowana przez dostawcę JPA, który nie wspiera jej. Jeden
persistence.xml wystarczy.

Jacek