이전 프로젝트에서 COM+를 사용했던 적이 있었습니다. 나중에는 퍼포먼스 상의 이슈로 빼긴 했지만, 정말 마음에 들었었던 부분이 있었으니 바로 "생산성"입니다.
일반적인 3-tier 웹 프로젝트 환경에서 트랜잭션 처리를 하는 방법에는 대표적으로 3가지 정도가 있습니다. EnterpriseService(COM+)를 사용하는 것, ADO.NET Transaction을 사용하는 것, 데이터베이스 단의 SP 내에서 BEGIN TRAN/COMMIT TRAN을 사용하는 것 정도가 되겠네요. 선택 기준은 여러 가지가 있겠지만, 가장 밀접한건 역시 소프트웨어의 아케텍쳐가 되고요. Transaction Script 패턴을 사용하냐, Domain Model 패턴을 사용하냐, Table Module 패턴을 사용하냐에 따라서 트랜잭션을 걸어야 하는 위치가 달라지죠.
잠시 얘기가 빗나갔는데, 개인적으로 선호하는 방식은 Business Logic Layer단에서 트랜잭션을 진입하는 방식이고요. 그래서 더 COM+를 사용하고 싶었었나봅니다 ^^;; [이유 참 궁색] 또한 생산성 부분에서는 .NET Attribute를 이용해서 클래스 단위로 TransactionOption을 걸어주고, 메소드 단위로 AutoComplete를 걸어주게 되면 예외 발생시에 알아서 Rollback해주고, 예외가 없다면 Commit 해줍니다. 개발자가 트랜잭션 처리에 골머리를 앓을 필요 없이 편하게 개발만 하는거죠.
그치만 성능상의 민감한 문제와 운영의 어려움이라는 두 가지 문제가 존재합니다. 문제 발생시에 대처하기가 만만하지는 않더라고요. 그래서 최근에 새로운 프로젝트를 하면서 이러한 문제 때문에 고민을 좀 했었습니다. 그런데 때마침 구글신께서 적절한 링크를 던져주시더군요.

질러라! (응?)
Declarative Progarmming using ADO.NET and without EnterpriseService.
http://www.codeproject.com/dotnet/declarativetransactions.asp
닷넷에서 도입된 여러 가지 개념중에 하나인 Context를 이용해서 선언형 프로그래밍을 하는 아이디어더군요. 눈이 번쩍 +ㅁ+ 띄였습니다. [Article 쓰여진 날짜를 보고 좌절을 좀 했지만요.. 2001년 10월..OTL]
요약하자면, 간단합니다.
객체를 활성화시킬 때 CLR에서는 먼저 객체의 Metadata를 뒤져봅니다. 여기에 Database Connection과 Transaction에 관한 Attribute를 추가해놓습니다. 이 Attribute에는 현재 속성값에 따라서 적절하게 커넥션을 생성해주고, 트랜잭션을 생성해주고, 커밋하고 롤백하는 로직이 들어가있고요. 이는 현재 활성화된 컨텍스트의 Properties를 찾아 보고 컨텍스트 안에서 객체들이 활성화 됨으로써 가능합니다. 현재 활성화된 컨텍스트가 없다면, 옵션에 따라서 새로 만들고요. Object Chain에 슬쩍 끼어 들어가는 거죠.
Decouple Components by Injecting Custom Services into Your Object's Interception Chain
http://msdn.microsoft.com/msdnmag/issues/03/03/ContextsinNET/default.aspx
위 글에 적절한 그림과 설명이 잘 나와있네요 =D
아무튼 .NET 1.1까지 적용될만한 내용이고요, 2.0에서는 아직 제대로 보지는 못했지만 System.Transactions 네임스페이스 안에 뭔가 있을 것 같습니다. 점점 개발하기 편해지는 세상에 오고 있네요. [그래서 무섭습니다만]
날씨도 우중충한데, 게을러지기 위해서 프레임워크 디자인을 잘 해봅시다. 'ㅁ'/
제루 Season 2, @Tokyo