Abstraction for user notification

Let me restate your problem, so I can describe my guess about where the core problem is located.

Your idea is to let the database layer return some object ("Notification") about the last operation's result, and to have a GUI component ("Notifier") which processes that object generically. Unfortunately, this approach reaches its limits in contexts where the result is not just "Ok" or "Error occured, try something else". A "retry" logic then may require a change in control flow in the non generic part of the GUI, and since your GUI always has to expect the DB to return a notification which requires a "Retry" logic, you may need to add the do ... while (userChoice == UserChoice.RETRY) ceremony in all kinds of places, even when it is unlikely that it is needed.

This, however, contradicts your idea of simplifying the GUI code by introducing the Notifier - instead of making the code less complicated, it becomes more complicated in several places. Note this problem will remain even when changing the interface from one method into two, hence I would stay with the one-method interface, which is simple and understandable as it is.

I think you have the following options:

1. Live with it, and implement the usage of Notification always with do ... while (userChoice == UserChoice.RETRY).

   Advantage: it's dead simple. The logic whether a "retry" makes sense or not is kept inside the DB layer.

   Disadvantage: extra boilerplate code in more places than needed. Since the UI has no knowledge if a retry could be sensible, the do-while loop will have to be added in every place where the notififer is used.

2. Live with it, but add do ... while (userChoice == UserChoice.RETRY) only in contexts where you know a "Retry" makes sense.

   Advantage: in the 90% of all cases where a retry does not make sense, the code is kept simple. If a required change of control flow looks different, it can be implemented easily.

   Disadvantage: this is a DRY violation - the knowledge that a retry can make sense (or may be required) is duplicated in the GUI layer as well in the DB layer. There is some risk the DB layer may request a retry, but the GUI forgets to support it!

3. Keep the whole knowledge that a retry makes sense inside the database layer. Implement the retry logic generically inside some GUI component DBResponseProcessor, which calls the Notifier, like this

   class DBResponseProcessor,
   {
       void process(MyDbOperation dbOperation)
       {
            UserChoice userChoice;
            do {
              Notification procedureNotification = dbOperation();
              userChoice = notifier.notify(procedureNotification);
            } while (userChoice == UserChoice.RETRY);            
       }
   }
   

   Now, the user of this component has to pass a lambda expression for the db operation, like

      dbResponseProcessor.process(
         () -> service.performSomeProcedure(someInputs)
      );
   

   Advantage: calling code is short, the retry loop is implemented only once and does not leak into the calling code.

   Disadavantage: the reusable component is more complex, my above scetch is probably not sufficient and you need to work out the details. You may consider to merge "Notifier" and "DBResponseProcessor" into one component, for example. Moreover, the retry flow is fixed, other control flows may require additional generic code.

4. Keep the whole knowledge that a retry makes sense inside the GUI layer. Will look similar to 3, but here it makes sense to have two entry points like process and processWithRetry

   class DBResponseProcessor,
   {
       void process(MyDbOperation dbOperation);
       void processWithRetry(MyDbOperation dbOperation);
   }
   

   Note, in this case, the processWithRetry does not need to return anything, since the retry logic is completely managed inside the component.

You will have to decide whether the 3rd or 4th option is worth the hassle, or if you can live with the more simpler options.

Let me add that in my experience, an immediate "retry" of a database operation makes only sense in very rare cases. Usually, a user needs to check the reason for a failed database operation, reestablish a connection first, fix something in the data, or restart the application. These are things they have to do separately first before a retry has a chance to succeed. So you should check if you really need the "retry" logic in a fully generic fashion, or whether it really makes sense to let the database layer decide alone if a retry should be done.