Avatar billede simonvalter Praktikant
02. september 2004 - 02:31 Der er 4 kommentarer og
1 løsning

exception og dao

jeg sidder og kigger på noget kode og undrer mig lidt over hvorfor en del af det er lavet som det er.

programmet er dette
http://www.javaworld.com/javaworld/jw-07-2004/jw-0719-jsf.html
http://www.javaworld.com/javaworld/jw-07-2004/jsf/jw-0719-jsf.zip

det som jeg ikke kan forstå er at han bruger dao pattern

model/dao/UserDao.java
model/dao/hibernate/HibernateDaoImpl.java

det er så fint nok og resten af systemet burde ikke have mere med hibernate at gøre.. skulle man tro?

Så har han
model/service/UserService.java
model/service/impl/UserServiceImpl.java

som gør brug af UserDao og begynder også at gøre brug af unchecked Hibernate Exceptions f.eks HibernateObjectRetrievalFailureException

Jeg vil tro han har styr på hvad han laver men ville det ikke være mere rigtigt at catche den exception i under dao
og throw den videre som en mindre specifik exception der ikke ville kræve en ændring hvis f.eks hibernate blev udskiftet med jdo eller har han en god grund til det han laver?
Avatar billede arne_v Ekspert
02. september 2004 - 09:33 #1
Umiddelbart (jeg har ikke checket koden) lyder det da som om at du har ret.

Der er ikke meget encapsulation hvis den kaldende kode catcher implementation
specific unchecked exceptions.

Umiddelbart virker det mest logisk enten at catche og throw en checked
exception nede i dao laget eller at catche alle runtime exceptions i den
kaldende kode.

Men der er mange forskellige opfattelser af hvordan exceptions skal bruges.

Bare fordi noget er publiceret i JavaWorld behøver koden ikke være god. Heller
ikke selvom "best practice" nævnes en snes gange i teksten.

Men du kunne vel skrive til forfatteren og spørge ham, hvorfor han har lavet
det på den måde.
Avatar billede simonvalter Praktikant
02. september 2004 - 14:45 #2
Ok rart at høre at jeg ikke er helt forkert på den.
Tror jeg vil tage dit råd og skrive til ham.

Du må godt smide et svar, tak for hjælpen.
Avatar billede arne_v Ekspert
02. september 2004 - 16:17 #3
ok
Avatar billede simonvalter Praktikant
03. september 2004 - 04:44 #4
Her er svaret fra ham der har lavet det:

Simon,

This is a good question and the answer is not short :)

Spring uses a different way to handle excpetion. Spring likes runtime exception, which does not force you to catch it. Whether or not to use Runtime exception or checked exception, there're a lot of discussions.

DAO helps you to isolate the data access logic,Hibernate vs. JDBC, Oracle vs. MySQL, etc. You are right, if you want to achieve a clear isolation between integration and business logic tier, u'd better define a whole bunch of data access exceptions and catch all exception in the intergration tier and rethrow as the new data access exception. However, sometimes, u realize for most application, it's pretty much a catch and rethrow and it's not doing any actual work.

The integration tier and business logic tier are tightly coupled, and sometimes they are refered as the middle tier. So, it's really up to you whether or not to make the clear seperation.

The answer - ideally, u should create data access exception and make the clear seperation. In the real world, maybe not. As long as you modulize your application, once the implementation change, there're only a minimum components need to be changed, it should be good enough.

Hopefully, it answers your question!

cheers,

Derek
Avatar billede arne_v Ekspert
11. september 2004 - 18:09 #5
Det betyder vist løst oversat: "Vi fandt det for ubetydeligt til at vi gad bruge tid på det".
Avatar billede Ny bruger Nybegynder

Din løsning...

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.

Loading billede Opret Preview
Kategori
Kurser inden for grundlæggende programmering

Log ind eller opret profil

Hov!

For at kunne deltage på Computerworld Eksperten skal du være logget ind.

Det er heldigvis nemt at oprette en bruger: Det tager to minutter og du kan vælge at bruge enten e-mail, Facebook eller Google som login.

Du kan også logge ind via nedenstående tjenester