23. juni 2008 - 18:33Der er
8 kommentarer og 2 løsninger
Er EJB et must til databaser?
Hej,
jeg vil lave en klient-side front-end en database. Jeg bruger netbeans og har brugt en frygtelig masse tid med dens wizards som opretter entitet objekter og laver persistance managers og query objekter i gui-editoren. Jeg er nu stødt på en begrænsning når jeg vil lave avancerede queries med joins og aggrigate-funktioner som ikke returnerer nogen specifik entitet, men noget sammensat.
Mit store spørgsmål er: er det yt of forbudt helt at droppe EJB, persistence api og simpelthen bare bruge JDBC med ad-hoc queries rundt omkring i min model? Bør min model i min java front-end være magen til entiterne i min database, når udgangspunktet er at databasen er designet før java-applikationen?
Jeg kan selvfølgelig regne ud at "det kommer an på situationen", men er der nogen der har en fornemmelse om, om det er gammeldags og yt at bruge JDBC direkte, og jeg derfor bør lære EJB ordenligt?
(jeg bruger O/R mappere som paraply for EJB2, EJB3, JPA, Hibernate, JDO etc.)
De er best practice naar man er interesseret i enkelt objekter. Hvilket vel er typisk for online brug (CRUD stuff).
De er absolut en daarlig ide, naar man vil arbejde med opsummeringer/statistik/rapporter, fordi saa er performance alt for daarlig.
Til den slags er ren JDBC (eller et tool beregnet til den slags oven paa JDBC) bedre.
For den sags skyld kan man godt bruge JDBC i en session bean.
Hvis dit problem falder i den sidste kategori, saa drop ORM til fordel for SQL (husk dog at goer dig lidt umage for at den SQL er portabel !!) - hvis dit problem falder i den foerste kategori, saa skal du nok studere din ORM implementation lidt bedre.
Ofte kan man lave selv ret avancerede queries via ORM. Men nogen gange er det nemmest at hente en stribe objekter via ORM og saa viderebehandle dem i Java. Kunsten er at finde det bedste vaerktoj til ens problem stilling.
Hvis du forklarede lidt mere om havd du vil, saa kan du maaske faa et mere konkret raad.
Som du påpegede var mit spørgsmål lidt abstrakt. Mit spørgsmål var generelt ang. ORM vs. direkte database kald, men jeg vil da meget gerne uddybe mit specifikke tilfælde hvis du ville give et råd :-) Jeg er ved at skræddersy et cms system som opfylder et par særlige behov. Jeg vil lave editoren som en java desktop applikation, med gui tegnet i netbeans' gui editor. Det er kun editoren dette spørgsmål drejer sig om. Jeg har ikke erfaring med ORM, men har gennem et par grundlæggende kurser på mit universitet erfaringer i at skrive halv-avancerede SQL queries.
Kernen i dette system er min relationelle database som jeg har designet og lagt mig fast på. Altså vil jeg ikke blot bruge min database som et persistencelager for mine objekter i front-enden, men derimod som hjertet i applikationen. Er dette en usædvagentlig indgangsvinkel? Efter at læse nogle timer om EJB bliver jeg i hvert fald i tvivl.
Vil det være håbløst forældet simpelthen at bruge JDBC til at lave queries og få returneret arrays af strings som jeg sætter direkte i view-komponenterne? Den største motivation til at skyde denne genvej er, at jeg på denne måde kan nøjes med noget der ligner 50-100 linjers ODBC-relateret kode, fremfor et utal af enitets-klasser og en masse kompleksitet med beans-bindings osv.
Traditionelt har EJB folket betragtet databasen som noget der skulle vaere saa simpelt som muligt.
Af flere aarsager: - man prioriterer portabilitet mellem forskellige database - af en eller anden grund foretraekker app folk at have logikken i app og database folk i db
----
For mig lyder det som om at du ligger lige paa graensen mellem ORM og SQL.
Du kan lave en server metode som returnerer en collection af strings og henter dem via plain JDBC og en SQL saetning.
Eller du kan lave en server metode som returnerer en collection af strings og henter dem via ORM - og maaske kan det laves simplere end du beskriver - du behoever ikke at bruge 1 tabel----1 klasse.
tak for dine kommentarer, det har hjulpet. Mht. app-server-db vs. app-db, så bliver det nok app-db, da det andet ville være overkill til denne applikations størrelse. Men jeg skal huske til en anden gang at mellemliggende server er best practice.
Hej igen. Det med hardkodning af adgangskode er nu ikke noget særligt problem i dette tilfælde, da det kun skal bruges internt i huset af folk der alligevel har fuld adgang til database serveren. Tak for hintsne. Tror måske jeg må læse lidt op på EJB inden jeg beslutter mig helt :-)
Tilladte BB-code-tags: [b]fed[/b] [i]kursiv[/i] [u]understreget[/u] Web- og emailadresser omdannes automatisk til links. Der sættes "nofollow" på alle links.
