Comments / Profile of aa0ndrey / Habr

Андрей Алексеев @aa0ndrey

User

Подробное руководство по инверсии зависимостей. Часть 1

aa0ndrey Oct 17 2021 at 20:08

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

Если бы была цель написать про transactionManager, то это было бы безусловно верно. Статья не про TransactionManager. У вас есть сомнения, что предложенные методы могут и добавить rollback и проверку наличия транзакции?

С этим согласен, но предлагаемое решение -- реально жесть и мусор. Транзакции -- контекстно зависимая вещь. Чтобы скрыть детали реализации самым лучшим способом будет поставить AOP interceptor вручную или при помощи аннотации фреймворка. Если нет фреймворка -- то в тыщу раз лучше оставить TM как явную зависимость в бизнес коде.

Прошу выбирать выражения. Если вам не нравится решение, это можно выразить другим способом или вы считаете такую риторику уместной?

Об этом тоже указал в статье. Для transaction manager лучшее решение будет продемонстрировано во второй части с использованием модуля application. Тут нет цели продемонстрировать фреймворк или как пользоваться AOP.

Замечу, что AOP это по своей сути, по крайней мере если мы говорим про аналог реализации @Transactional , реализация паттерна декоратор. То что это решение (с декаратором) предпочтительнее я указал как в статье, так и в коментарии тут

Почему оставить TM в бизнес коде это плохо указал как в статье, так и в комментариях выше

Это очень хреновое решение, хуже может только использование EventBus. Обзерверы -- это антипаттерн, служащий в основном, чтобы слабо связать компоненты и передать событие от более низкого компонента в иерархии к более высокому. Он вводит в код неявные трудноразрешимые динамические зависимости, о которых ничего не известно из контекста кода. Соответственно трудно читать, трудно поддерживать, трудно отлаживать и вообще все плохо. Конкретно здесь не нужна слабая связанность нужно объявить въявную зависимость кода от TM. Тем более, зачем использовать списки, если в контексте есть только единственный хендлер. Делать излишнюю абстракцию для удовлетворения конкретного кейса себе и другим дороже.

Второй раз обращу внимание на ваш способ общения. Это деструктивно для ресурса. Если вы несогласны это можно выразить иначе. Желание вести с вами дискуссию и отвечать практически нет.

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

Но вы драматизируете. Весь UI строится на наблюдателях, также большинство фреймворков в качестве механизма расширения используют наблюдателей. Тот же Spring с его PostConstruct и PostDestroy и другие события жизненного цикла бина. Принципиального отличия от onStart и onEnd в этом плане нет. Плагины расширения также строятся на наблюдателях. Есть событийно ориентированные архитектуры. Заявлять, что наблюдатель является антипаттерном очень смело с вашей стороны.

Как вседа оптимистичное программирование для идеального мира, где по небу летают розовые пони, а код никогда не ломается. Если свалится первый обработчик -- другие что, не получат сообщения? А должны? Если свалится дальнейший код в теле метода, обработчики не получат end, а транзакция никогда не закроется? А если первый обработчик получил onStart(), а второй свалился, нужно ли будет первому послать onEnd()? И еще куча пессимистичных нюансов, которые превратят данный паттерн в настоящий геморрой. Так что на свалку данный велосипед.

Нет никакого оптимистичного программирования. Если свалится первый обработчик, то либо в обработчике должна быть конструкцию try-catch, если мы подразумеваем, что что-то необходимо сделать в случае проблемы с обработкой, либо если обработчик упадет, и есть какая-то общая стратегия по обработки exception-ов, то exception должен пролететь как есть до места, где его словят. Если мы говорим про Spring, то это может быть ExceptionHandler.

Если вас интересуют возможность try - catch - finally, чтобы в одном месте открыть транзакцию, а в другом гарантировано закрыть, то посмотрите на сообщение тут

Так что на свалку данный велосипед.

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

-------------

Надеюсь данный пример решить все возникщие у вас вопросы.

Представим код без использования наблюдателей, с TransactionManager у которого есть 4 метода

interface TransactionManager {
  void begin();
  void commit();
  void rollback();
  boolean hasActive();
}

class OrderService {
  public void create(CreateOrderRequest request) {
    try {
      if (!transactionManager.hasActive()) {
        transactionManager.begin();
      }

      //some domain code

      transactionManager.commit();
    } catch (Exception e) {
      if (transactionManager.hasActive()) {
        transactionManager.rollback();
      }
    }
  }
}

Теперь рассмотрим тот же пример, но с наблюдателями

class OrderService {
  public void create(CreateOrderRequest request) {
    try {
      observers.forEach(observer -> observer.onStart());
      
      //some domain code
      
      observers.forEach(observer -> observer.onEnd());
    } catch (Exception e) {
      observers.forEach(observer -> observer.onCreationFailed(e);
    }
  }
}
                        
class CreateOrderObserverImpl {
  public void onStart() {
    if (!transactionManager.hasActive()) {
      transactionManager.begin();
    }
  }
  
  public void onEnd() {
    transactionManager.commit();
  }
  
  public void onCreationFailed(Exception e) {
    if (transactionManager.hasActive()) {
      transactionManager.rollback();
    }
  }
}