Comunicar conflictos de concurrencia a la capa de aplicación

Question

Al comunicar los conflictos de concurrencia a su capa de aplicación, ¿existe una alternativa al usar excepciones que también respete el principio de Separación, ¿O las excepciones son el mejor mecanismo que tenemos (en los idiomas que apoyan las excepciones)?

En las intestinos de mi aplicación, tengo una lógica de bloqueo optimista que ejecuta algunas capas hacia abajo cuando llamo ciertos métodos de alto nivel, por ejemplo, (en mi caso, estoy usando una capa de acceso de datos personalizado, aunque ciertamente estoy abierto a escuchar cómo las implementaciones de ORM hacen esto). El método de alto nivel llama que interactúa la aplicación se ve así:

// 'data' is just a placeholder for multiple parameters, including something
// that contains row version information
void Customer.UpdateInformation(object data);

Necesito poder informar a los usuarios una aplicación web cuando alguien más ha actualizado los datos en los que está trabajando.

Prefiero no devolver un valor de los métodos que cambian los datos. Entonces, en el pasado, he lanzado excepciones (similar a la API del adaptador de datos .NET, que arroja una DbconcurrencyException Cuando detecta conflictos), pero los conflictos de concurrencia no son, de alguna manera de sentido común, excepcional. Son un hecho de la vida: una parte predecible y esperada del flujo de trabajo de la aplicación. ¿Califican como excepciones exógenas, en la taxonomía de Eric Lippert?

Answer 1

En mi opinión, las excepciones son la mejor manera de comunicar este tipo de errores. Creo que su solución es bastante correcta, porque lanza un tipo específico de excepción que puede atrapar en la capa de presentación. La capa de presentación puede usar la información en esa excepción para mostrar al usuario.

Si bien las excepciones son la mejor manera, crear una buena experiencia de usuario puede ser muy difícil. Lo más simple sería decirle al usuario que había un conflicto y elegir si le gustaría perder sus cambios o anular los nuevos cambios. Se pone difícil cuando desea mostrar los conflictos o dejar que el usuario elija qué valores anular y cuáles no. O al menos, es muy difícil hacer esto de manera genérica. Posiblemente necesitaría una interfaz específica para resolver tales conflictos para cada pantalla en su sistema donde podrían ocurrir conflictos.

En los sistemas en los que trabajé, casi no captamos esas excepciones para mostrar al usuario. Principalmente tratamos de evitar que ocurran esos conflictos cambiando los procesos detrás de él. Por supuesto, depende totalmente de su tipo de aplicación y de la forma en que funciona el negocio (o le gusta trabajar) qué solución es mejor.