java - mvc - Manejo de excepciones de Dao en la capa de servicio

spring java tutorial

Question

Si mi capa Dao genera excepciones específicas, ¿el manejo de ellas en mi capa de servicio constituye una pérdida de preocupaciones? En caso afirmativo, ¿debería hacer las excepciones genéricas e independientes de cualquier capa para abordarlas o hay alguna otra forma?

La misma pregunta es aplicable a las excepciones de manejo de la capa UI lanzadas por la capa de servicio.

Answer 1

Buena pregunta..!! El manejo de las excepciones en la capa UI (por ejemplo, la capa de acciones si está utilizando puntales) es un buen enfoque. Hacer excepciones genéricas no es una buena manera de lidiar con este problema. Cada capa debe tener sin embargo sus excepciones específicas como genéricas. por ejemplo, la capa DAO puede tener controladores de excepciones personalizados como DavaSavingException, IOException, etc.

Así que el enfoque es lanzar una excepción de DAO a la capa de servicio y nuevamente lanzarla a la capa UI y capturarla en clases específicas de la UI.

Sin embargo, las cosas son demasiado diplomáticas dependiendo de sus aplicaciones / necesidades.

Answer 2

Cuando creamos una aplicación en capas, siempre hay una capa de usuario y otra capa usada. Para este caso, la capa UI -> usa la capa de servicio -> usa la capa DAO.

Ahora es muy subjetivo y abierto a interpretaciones. Pero el objetivo debe ser un buen grado de desacoplamiento . Para lograr esto, una salida es definir excepciones genéricas específicas de capa , como PersistentException , ServiceException , etc. Esta excepción incluirá la excepción específica de la capa real.

Por ejemplo, diga si hay algún error en el lado de la base de datos (violación de restricción, etc.), cámbielo en PersistentException y deje que la capa de servicio lo maneje (en cuanto a cómo transmitir esto a la capa UI de forma genérica)

Ahora, dado que la integración entre la capa de servicio y la capa DAO es contractual (basada en la interfaz), la capa DAO es libre de cambiar la implementación a cualquier cosa siempre que cumpla con el contrato de la interfaz . Por lo tanto, si cambia la implementación que produce algunas excepciones nuevas, esas excepciones nuevas pueden ajustarse en PersistentException y la capa de servicio no se verá afectada .

Answer 3

Sí. es una buena idea crear sus propias excepciones independientes para cada capa.

Por ejemplo, si está utilizando una implementación DAO particular, debe ajustar la excepción específica de la implementación a su propia excepción genérica y enviarla a la capa de servicio.

Sin embargo, debe ser sensible a la hora de crear su propia jerarquía de excepción, de modo que no sea una sobrecarga para el desarrollo de la aplicación, así como su capacidad para mantener la información requerida en la capa de servicio. La mayoría de las veces, los códigos de error personalizados con una excepción genérica son suficientes.

Se puede usar algo como esto para simular una excepción específica de la implementación y lanzarla a la capa de Servicio.

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

Lanzar desde la implementación de DAO:

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

Acerca de la fuga de la preocupación: es posible que no desee que su capa de servicio se preocupe por todas las excepciones, como:

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

Por lo tanto, la llamada debe tomarse en función de las necesidades de la aplicación.

Answer 4

Su capa DAO ya tiene fugas en la capa de servicio cuando realiza operaciones como:

userDAO.persist(user);

Las excepciones, al ser parte de la API al igual que la operación, deben considerarse de la misma manera.

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

Las fugas pueden ocurrir con excepciones de tiempo de ejecución, o cuando se vuelven a lanzar las excepciones

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

Pero incluso esto suena mejor que las excepciones "independientes de la capa"