Obsługa wyjątków Dao w warstwie serwisowej

Question

Jeśli moja warstwa Dao rzuca wyjątki Dao, to czy obsługa ich w mojej warstwie usługi stanowi przeciek problemów? Jeśli tak, to czy powinienem uczynić wyjątki generycznymi i niezależnymi od jakiejkolwiek warstwy, która mogłaby zająć się tym, czy jest jakiś inny sposób?

To samo pytanie dotyczy wyjątków obsługi warstw interfejsu użytkownika zgłaszanych przez warstwę usługi.

Answer 1

Gdy tworzymy aplikację warstwową, zawsze jest warstwa użytkownika i inna używana warstwa. W tym przypadku warstwa interfejsu użytkownika -> używa warstwy usługi -> używa warstwy DAO.

Teraz jest bardzo subiektywna i otwarta na interpretacje. Ale celem powinien być dobry stopień oddzielenia od. Aby to osiągnąć, jednym wyjściem jest zdefiniowanie określonych wyjątków specyficznych dla warstwy np. PersistentException, ServiceException itd. Ten wyjątek zawinie faktyczny wyjątek dla warstwy.

Na przykład powiedzieć, czy istnieje jakiś błąd na stronie bazy danych (naruszenie więzów itp), owinąć że w PersistentException i niech warstwa usługa poradzić (w jaki sposób przekazać to do warstwy UI w sposób ogólny)

teraz ponieważ integracja pomiędzy warstwą usług i warstwy DAO jest umowna (interfejs oparty), warstwę DAO może swobodnie zmienić implementację do niczego, dopóki przestrzega umowy interfejsu. Więc jeśli zmienisz implementację, która rzuca kilka nowych wyjątków, te nowe wyjątki mogą być zawijane w PersistentException i Warstwa usługi pozostaje niezmieniona.

Answer 2

Dobre pytanie .. !! Obsługa wyjątków w warstwie UI (na przykład warstwa akcji, jeśli używasz rozpórek) jest dobrym podejściem. Wykonywanie wyjątków nie jest dobrym sposobem radzenia sobie z tym problemem. Każda warstwa powinna mieć jednak określone wyjątki jako ogólne. na przykład warstwa DAO może zawierać niestandardowe procedury obsługi wyjątków, takie jak wyjątek DavaSavingException, wyjątek IOException itp.

Podejście to polega na wyrzuceniu wyjątku z DAO do warstwy usługi i ponownemu przesłaniu go do warstwy interfejsu użytkownika i przechwyceniu określonych klas interfejsu użytkownika.

Jednak sprawy są zbyt dyplomatyczne w zależności od twoich aplikacji/potrzeb.

Answer 3

Tak. dobrym pomysłem jest stworzenie własnych niezależnych wyjątków dla każdej warstwy.

Na przykład, jeśli używasz konkretnej implementacji DAO, powinieneś zawrzeć wyjątek dotyczący implementacji do własnego ogólnego wyjątku i przekazać go do Warstwy usługi.

Należy jednak zachować wrażliwość podczas tworzenia własnej hierarchii wyjątków, tak aby nie stanowiła obciążenia dla tworzenia aplikacji, a także by była w stanie utrzymać informacje wymagane w Warstwie usługi. W większości przypadków wystarczają niestandardowe kody błędów z ogólnym wyjątkiem.

Coś w tym stylu może być używane do symulacji wyjątku dotyczącego implementacji i zgłaszane do warstwy usługi.

class AppDAOException extends Exception { 
    public final static int _FAIL_TO_INSERT = 1; 
    public final static int _UPDATE_FAILED = 2; 
    public final static int _SQL_ERROR = 3; 
    private int errorCode; 
    public AppDAOException(int errorCode) { 
     this.errorCode = errorCode; 
    } 
    public getErrorCode() { 
     return errorCode; 
    } 
} 

rzucanie z realizacji DAO:

try { 
    //code here 
} catch (some.impl.SQLSyntaxException e) { 
    throw new AppDAOException (AppDAOException._SQL_ERROR); 
} 

O wycieku niebezpiecznej: może nie chcieć swoją warstwa usługa przejmować się wszystkimi wyjątkami - takimi jak:

} catch(NoRowExistsException e) { 
    return null; 
} finally { 
    //release resources 
} 

Tak połączenie musi zostać wykonane w zależności od potrzeb aplikacji.

Answer 4

Twój warstwy DAO już przecieka do warstwy usług podczas wykonywania operacji takich jak:

userDAO.persist(user); 

wyjątkami, będąc częścią API podobnie jak operacja powinna być traktowany w taki sam sposób.

try { 
    userDAO.persist(user); 
} catch (DAOException e) { 
    // looks fine to me 
} 

Przeciek może zdarzyć się wyjątki w czasie wykonywania, lub gdy rethrow wyjątki

try { 
    userDAO.persist(user); 
} catch (SQLException e) { 
    // sql implementation exposed 
} 

Ale nawet to brzmi lepiej niż „warstwy” niezależnych wyjątki