Когда в последний раз я консультировал одну компанию, мы обсуждали внутренний SOA фреймворк, который должен взаимодействовать с базами данных предприятия. Этот фреймворк был SOA только разве что по названию, полностью доморощенный, и что самое грустное, он был «любимым проектом» начальника отдела ИТ. Он был не безопасным и построен на сомнительных технологиях и решениях. В общем он был сделан для решения некоторой проблемы, которой либо не существует, либо она не могла была разрешима боле простыми средствами. Моя команда была крайне разочарована структурой этого фреймворка. Но, в качестве консультанта, очень часто приходится сначала продумать пути решения проблемы, нельзя порсто сказать заказчику что его продукт «плохой», необходимо сначала построить его доверие к себе, и только потом решать более серъезные проблемы. Так или иначе такой процесс может занять годы, и все зависит от фирмы, в которой будут происходить такого рода изменения. Тогда я и задумался над тем чтобы начать использовать аспектно-ориентированный фреймворк чтобы решить эту проблему

Все исходные тексты приведенных программ доступны по ссылке: GitHub

В тоже самое время мы были обречены на провал с этим фреймворком, поскольку он абсолютно не предназначен для многопоточных приложений (например, для web-сервера). Из-за этого постоянно случаются аварии, а иногда он может просто ни работать ни запускаться. Мы должны были построить рабочие и хорошо отлаженные приложения вокруг этого беспорядка и хаоса в первую очередь потому что мы хотим построить к себе определенный уровень доверия со стороны фирмы-заказчика. То что мы уже сделали для этой фирмы, можно посмотреть в предыдущих статьях: это и логгирование и перехват ошибок. Это работало хорошо, и скрывало все «гадости» от конечного пользователя. Однако для того чтобы пользоваться этой системой, необходимо защищать каждый участок кода, который с ней соприкасается. И, делая это, я довольно быстро устал. Ведь представьте: для каждого метода, который вызывали во фреймворке или считывали значения свойств и полей классов, было необходимо провесети одинаковые проверки, и при этом не переборщить: иначе мы теряем в производительности.
Однако, хватит разглагольствовать о старых проектах, поговорим о деле: вы можете использовать PostSharp для управления транзакциями, независимо от того, строите вы свое приложение на доморощенных фреймворках или нет. Вот простой пример OnMethodBoudaryAspect, который даст вам пример основ типичной поддержки транзакций:

[Serializable]
public class TransactionScopeAttribute : OnMethodBoundaryAspect
{
        [NonSerialized] private ICharityService _charityService;
        private string _methodName;
        private string _className;

        public override void CompileTimeInitialize(MethodBase method, AspectInfo aspectInfo)
        {
                _className = method.DeclaringType.Name;
                _methodName = method.Name;
        }

        public override void RuntimeInitialize(System.Reflection.MethodBase method)
        {
                // in practice, the begin/rollback/commit might be in a more general service
                // but for convenience in this demo, they reside in CharityService alongside
                // the normal repository methods
                _charityService = new CharityService();
        }

        public override void OnEntry(MethodExecutionArgs args)
        {
                _charityService.BeginTransaction(); 
        }

        public override void OnException(MethodExecutionArgs args)
        {
                _charityService.RollbackTransaction();
                var logMsg = string.Format("exception in {0}.{1}", _className, _methodName);
                // do some logging
        }

        public override void OnSuccess(MethodExecutionArgs args)
        {
                _charityService.CommitTransaction();
        }
}

Все действительно просто и здесь нет абсолютно ничего нового относительно моих более старых статей. Заметьте, что здесь было бы здорово перегенерировать исключение в случае отката транзакции, и именно это и делается по умолчанию (в коде, который вызывает onException). Все что вам надо сделать – пометить методы, в которых необходимо поддержать транзакции атрибутом [TransactionScope], и вы убережете себя от написания try/catch begin/commit/rollback кода все снова и снова одним простым аспектом. Также мы вынесли общий код в одно место, и можем таким же образом добавить логгирование или какой-либо специальный метод перехвата исключений.
Один из случаев, кода код выше не будет работать должным образом, это вложенные транзакции. В моем коде, изложенном выше, методы Begin/Commit/Rollback всего лишь пустышки, которые на самом деле ничего не делают. В конечном приложении, которое вы будете разрабатывать, менеджмент транзакий сильно зависит от метода доступа к данным. Если вы используете ADO.NET соединения, такие как SqlConnection, ODBC, Oracle, и проч., тогда вы скорее всего будете использовать TransactionScope (не перепутайте с названием аспекта) чтобы сделать внедрение транзакций простым и поддерживаемым. Однако если вы используете некоторую самостоятельную технологию, вы будете использовать совершенно иной API и вам потребуются дополнительные решения.
Теперь, когда у нас есть базовый аспект поддержки транзакций, давайте вернемся к моему изначальному примеру. Сервис, который я использую, постоянно ломается. Потому я напишу некий цикл, который будет пытаться сделать операцию до тех пор, пока операция не пройдет успешно. И, конечно, я не хочу чтобы попытки были постоянными и переросли в бесконечный цикл. Поэтому, введем ограничения на количество попыток. Также пусть мы точно знаем что признаком неудачной попытки служит исключение DataException, а все остальные исключения говорят нам о том что все дальнейшие попытки провести операцию предпринимать бесполезно. Поэтому мы залоггируем такие исключения и перестаним предпринимать попытки:

[Serializable]
public class TransactionScopeAttribute : MethodInterceptionAspect
{
        [NonSerialized] private ICharityService _charityService;
        [NonSerialized] private ILogService _logService;

        private int _maxRetries;
        private string _methodName;
        private string _className;

        public override void CompileTimeInitialize(MethodBase method, AspectInfo aspectInfo)
        {
                _methodName = method.Name;
                _className = method.DeclaringType.Name;
        }

        public override void RuntimeInitialize(System.Reflection.MethodBase method)
        {
                _charityService = new CharityService();
                _logService = new LogService();
                _maxRetries = 4;            // you could load this from XML instead
        }

        public override void OnInvoke(MethodInterceptionArgs args)
        {
                var retries = 1;
                while (retries <= _maxRetries)
                {
                        try
                        {
                                _charityService.BeginTransaction();
                                args.Proceed();
                                _charityService.CommitTransaction();
                                break;
                        }
                        catch (DataException)
                        {
                                _charityService.RollbackTransaction(); 
                                if (retries <= _maxRetries)
                                {
                                        _logService.AddLogMessage(string.Format(
                                                "[{3}] Retry #{2} in {0}.{1}",
                                                _methodName, _className,
                                                retries, DateTime.Now));
                                        retries++;
                                }
                                else
                                {
                                        _logService.AddLogMessage(string.Format(
                                                "[{2}] Max retries exceeded in {0}.{1}",
                                                _methodName, _className, DateTime.Now));
                                        _logService.AddLogMessage("-------------------");
                                        throw;
                                }
                        }
                        catch (Exception ex)
                        {
                                _charityService.RollbackTransaction();
                                _logService.AddLogMessage(string.Format(
                                        "[{3}] {2} in {0}.{1}",
                                        _methodName, _className,
                                        ex.GetType().Name, DateTime.Now));
                                _logService.AddLogMessage("-------------------");
                                throw;
                        }
                }
                _logService.AddLogMessage("-------------------");
        }
}

Да, это выглдит несколько пугающе! Но не беспокойтесь, давайте разберем все по кусочкам. CompileTimeInitialize и RuntimeInitialize вовсе не выглядят сильно отличными от тех, что описаны раньше: они всего лишь запоминают имена класса и метода и инициализируя сервисы, которые нам необходимы.
Для метода OnInvoke, давайте рассмотрим четыре возможных сценария работы:

Если метод отрабатывает без исключения, то это значит что все отлично работает.
Работа метода заканчивается неудачей и он выбрасывает исключение DataException, и мы еще не достигли ограничения в количестве повторов. Этот код находится в первой части оператора if/else первого блока catch{}
Работа метода заканчивается неудачей и он выбрасывает исключение DataException, и мы достигли ограничения в количестве повторов. Этот код находится во второй части оператора if/else первого блока catch{}
Метод выбрасывает другое исключение, сигнализируя о критической ошибке и невозможности повторов. За эту ситуацию отвечает код во втором блоке Catch{}

В моем простом приложении, я сделал сервис CharityService, который вылетает с ошибкой DataException в 50% случаев, а в оставшихся 50% — заканчивается удачно. Также примерно в 1 из 50 вызовов он возвращает не DataException, а какой-то другой. Если запустить пример, то сможете увидеть окно лога, в котором будет зафиксировано огромное количество попыток, и вызовов Begin, Rollback и Commit. Также пользователь увидит сообщение об ошибке в случае если программа сделала попыток больше чем разрешено либо если произошло исключение не явлюяющееся DataException.

Используя этот аспект, вы наделяете свое приложение некоторой роботизированностью в решении такого рода проблем. Код аспекта стал больше но он управляем. Если вы захотите получить что-то сложнее, тут будет иметь место рефакторинг: разделение на классы и методы, и прочие операции. Также можно использовать этот способ для того чтобы выстроить многопоточные обращения к методу в один поток.

Ссылки:

PostSharp. Менеджмент транзакций