Обработка исключений Dao в служебном слое

Ответ 1

Когда мы создаем многоуровневое приложение, всегда есть слой пользователя и другой используемый слой. Для этого случая слой UI → использует уровень сервиса → использует слой DAO.

Теперь он очень субъективен и открыт для интерпретаций. Но цель должна быть хорошей степенью развязки. Чтобы достичь этого, одним из путей является определение общих специфических для уровня исключений, скажем PersistentException, ServiceException и т.д. Это исключение обернет фактическое исключение конкретного уровня.

Например, скажем, если есть некоторая ошибка на стороне базы данных (нарушение ограничений и т.д.), оберните это в PersistentException и пусть уровень обслуживания обработает это (как передать это на слой пользовательского интерфейса общим способом)

Теперь, когда интеграция между уровнем обслуживания и уровнем DAO контрактной (на основе интерфейса), слой DAO может свободно изменять реализацию до тех пор, пока она подчиняется контракт. Поэтому, если вы измените реализацию, которая выдает некоторые новые исключения, эти новые исключения могут быть обернуты в PersistentException, а уровень сервиса остается незатронутым.

Ответ 2

Да. это хорошая идея создать собственные независимые исключения для каждого слоя.

Например, если вы используете конкретную реализацию DAO, вы должны перенести исключение конкретной реализации в свое собственное генерическое исключение и передать его на уровень обслуживания.

Однако вы должны быть чувствительны к созданию своей собственной иерархии исключения, чтобы не было накладных расходов на разработку приложений, а также способностью поддерживать информацию, требуемую на уровне обслуживания. В большинстве случаев этому свойственны специальные коды ошибок с общим исключением.

Что-то вроде этого можно использовать для имитации исключения, специфичного для реализации, и выбрасывается на уровень сервиса.

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;
    }
}

Бросание из реализации DAO:

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

Об утечке беспокойства: Возможно, вы не захотите, чтобы ваш сервисный уровень беспокоился обо всех исключениях, таких как:

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

Таким образом, вызов должен выполняться в зависимости от потребностей приложения.

Ответ 3

Уровень DAO уже течет в сервисный уровень, когда вы выполняете такие операции, как:

userDAO.persist(user);

Исключения, являющиеся частью API, как операция, должны рассматриваться одинаково.

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

Утечка может произойти с исключениями времени выполнения или при повторных исключениях

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

Но даже это звучит лучше, чем "независимые от уровня" исключения

Ответ 4

Хороший вопрос..!! Обработка исключений на уровне пользовательского интерфейса (например, слой действий, если вы используете struts) - хороший подход. Использование исключений generic не является хорошим способом решения этой проблемы. Каждый слой должен иметь свои специфические исключения как общие. например, на уровне DAO могут быть настраиваемые обработчики исключений, такие как DavaSavingException, IOException и т.д.

Таким образом, подход представляет собой исключение исключения из DAO на уровень обслуживания и снова бросает его на уровень пользовательского интерфейса и уловляет в определенных классах пользовательского интерфейса.

Однако все слишком дипломатично в зависимости от ваших приложений/потребностей.