トランザクションを使用したビジネスロジックとDBロジックの分離

アプリケーションには3つのレイヤーがあります。外部APIを提供するサービスレイヤー。ビジネスロジック用のBOレイヤー、およびデータベース接続用のDAOレイヤー。

ファイルを更新するたびに、フォルダ内の何か、たとえば「最終変更日」も変更したいとします。これは、トランザクションで実行する必要があります。成功し、ファイルとフォルダーの両方が編集されます。または、障害が発生し、トランザクションがロールバックされるため、両方のオブジェクトが以前の状態になります。

「ファイルが編集されたときにフォルダーを編集する」アクションは、純粋にビジネスロジックです。したがって、これはBOレイヤーに属していることを意味します。ただし、データベースにはObjectifyを使用しているため、トランザクションを開始するにはofy（）。transact（...）を呼び出す必要があります。BOレイヤーでこの関数を呼び出すと、ビジネスレイヤーでデータベース固有の呼び出し（Objectify）が発生するため、デザインが破損します。

この問題のクリーンなソリューションは何でしょうか？

トランザクションをどのように削減するかは、まさにビジネスロジックです。だから、DAOレイヤーが、transactあなたが言及したメソッド（そしておそらくのようなもの）に対して、dbフレームワークに依存しないAPIを提供するようにcommitしrollbackます。その後、データベースまたはデータベースフレームワークに依存せずに、BOレイヤーから使用できます。

以下のように見える客観化は、原子のような取引（のために設計されているGoogleのアプリケーションエンジン取引）。トランザクション管理の独自の抽象化を開発する必要があります。

この場合。抽象化が続くトランザクション管理を上位層に委任するにはどうすればよいですか？

@DocBrownアプローチは、指定されたアーキテクチャ（階層化されたアーキテクチャ）に実装するための、より高速でクリーンなソリューションを探しています。

アプリケーションとそのコンテキストに関する情報が多すぎるため、Docのソリューションも私にとって最も安全なようです。

ただし、ビジネスレイヤーのUnitOfWorkデザインパターンを確認することをお勧めします。Objectifyが目的とするトランザクション管理に適していると思います。

簡単に要約すると、このパターンはビジネスルールをビジネストランザクション（作業単位）にカプセル化することを目的としています 。このパターンにより、B.T間の継承が可能になり、これまでのところ、Objectifyも参照しています。構成もサポートします。したがって、構成または継承のいずれかによって、このアプローチでは複雑なB.Tsが許可されます。

指定されたアーキテクチャに適用すると、次のようになります。

FileService -> FileBO : new EditFileTransaction().execute()
                           |-> ofy().transact(...)
                           |--> FileDAO.actionA()
                           |--> FolderDAO.actionA()
                           |-> [ofy().commit(...)|ofy().rollback()]