トランザクションは再利用の敵である

釣りっぽいタイトル。「RDBのトランザクションが絡むとアプリケーション側のプログラムが書きにくくなる」という話です。 もちろんですが、RDBのトランザクション機能は偉大であり、Webアプリケーションでも意識して使わなければならず、「トランザクションなんて使うな」と言いたいわけではありません。 合成できない関数 PHPで素のPDOから考えます。たとえば、以下の関数に問題はあるでしょうか？ <?php /* * 古いデータをアーカイブテーブルに移す関数のイメージ */ function moveDataToArchive(PDO $db) { $db->beginTransaction(); try { $db->exec(' INSERT INTO archives SELECT * FROM data WHERE published < CURRENT_DATE '); $db->exec

[ledsun]

ビジネスロジックレイヤーでトランザクションを開閉すればOK。Webアプリは（大抵）リクエストとトランザクションが1対1で対応する。リクエストとBLの（公開）メソッドを1対1で対応させれば自ずと解決。

[k-holy]

トランザクション制御のインタフェース定義して、REST API ≒ユースケース単位のクラス(いわゆるトランザクションスクリプト？)にそれ渡してます

[ruicc]

HaskellのPersistentはモナドで合成してそのモナド走らせるときにトランザクション実行してますね。任意のロジックが再利用可能な形で記述でき、組み合わせられます。

[kuenishi]

トランザクションがどうこうじゃなくて、パラダイムの異なるふたつの言語をひとつのプログラムでグチャグチャに混ぜて使わざるを得ないせい。ちなみに関数型言語だと…ゴニョゴニョ

[ono_matope]

Transactionクラスを定義してもいいけどめんどい。ActiveRecordパターン使ってるとこういう事態になりがちだからDataMapper使おうぜってファウラーが言ってた気がする http://matope.hatenablog.com/entry/2014/05/13/193709

[indication]

似たようなことにはまったけど、レイヤーを増やせば機能がまとまって見易いはず。

[todesking]

トランザクションはmodelの外で仕込むようにしてるけど、なんかベターなモデルあるのかな

[Sampo]

トランザクションの扱いをライブラリ化したい場合に突き当たるはずの問題。SAVEPOINTを使えば部分ロールバックが可能なので、コンテクストに応じて使い分ければ何とか逃げ切れる。 http://qiita.com/yuba/items/9b5b86bc3e128a84db5e

[kimutansk]

関数とトランザクションが合わないなら、トランザクション制御をレイヤーで区切るなりした方がいいわけですかねぇ。考え方が違うので。

[potato777]

原因は設計。モデルでトランザクションしているから再利用できない。PHPのMVCならコントローラー(もしくはそのレイヤーのサービスクラス)でトランザクションスコープを持つ。 Nested Transaction は根本的解決ではない

[taka222]

”トランザクションは再利用の敵である - 泥のように”

[taketyan]

基本 Doctrine 方式。トランザクションマネージャはモデルの外出し。トランザクションを伴う操作はサービスクラスに分ける。単一メソッド内でトランザクションのネストは使わず、それを内包するサービスクラスを書く。

[you21979]

最近は無名関数使ってるかなぁ transaction(function(dbc){hoge(dbc);fuga(dbc);});

[yojik]

そこで Container-Managed Transaction ですよ。 → 2000年代のJ2EEの泥沼に戻る

[shimooka]

ListとかでDMLオブジェクトを保持・実行するトランザクションクラスを使うって感じ。そういう話ではない？

[localdisk]

トランザクションの境界を決めればいいんじゃないかなぁ。んでAOPとかフィルターとか。

[stk2k]

トランザクションスクリプトをドメインオブジェクトにしにくい例？