6


DAOが処理する必要のあるビジネスロジックの量について疑問に思いました。

わかりました。DAOの目的は、データアクセスをカプセル化し、データアクセスと実装に関するすべての情報を非表示にすることです。さらに、DAOの目標は、ビジネスロジックをデータアクセスロジックから分離することでもあります。

DAOにはビジネスロジックが含まれている必要があると私は主張します。たとえば、特定のドメインの要件のためにビジネスオブジェクトを削除または更新できなかった場合はどうなりますか？そのDAOの削除/更新メソッドを実装する人はいないと思います。これは、私が見ているように、ビジネスロジックに関するある程度の知識があることを意味します。

さて、あなたが想像できるように、私の質問は実際的というより概念的であり、使用の具体的なシナリオがないので、ORMを使用することは無意味なアドバイスです。

問題は、永続データの操作に制限がある場合、DAOが処理する必要のあるビジネスロジックの量です。

例：
BusinessObject1存続期間中に1回だけ更新できます。すでに更新されているかどうかを簡単に知ることができると仮定すると、DAOは、BusinessObject1再度更新しようとした場合に例外をスローする必要がありますか？または、何も検出せず、これをビジネスレイヤーで管理する必要がありますか？

4

4 に答える 4

10

参照整合性ルールを持つデータベースにデータを格納する場合、データ層にはビジネス ルールが含まれます。

これはすべての経験則の問題です。彼らは働かなくなるまで働きます。ポイントは、データ層のルールを避けることではなく、そこに属するデータ層にのみルールを配置することです。たとえば、格納されたデータの有効性を強制するルールは、データ レイヤーに属します。データの使用方法を強制するルールは、データ層には属しません。

于 2012-08-31T11:47:32.290 に答える
0

あなたの懸念はそれです

特定のドメインの要件により、ビジネス オブジェクトを削除または更新できなかった場合はどうなりますか?

ビジネス ロジックはほとんどの場合変化し続けるため、DAO とは別にビジネス ロジックを維持することをお勧めします。そのため、update n delete の実行中にビジネス上の制約を設ける必要がある場合は、サービス レイヤーでこの制約をチェックする必要があります。この方法では、DAO レイヤーに変更を加える必要はありません。

さらに、将来別のデータベースに切り替えたい場合でも、db 固有の操作に集中するだけでよいため、ビジネス ロジックについて心配する必要はありません。

于 2012-08-31T11:39:49.350 に答える
0

アプリケーションが互いに独立したコンポーネントに分割されている場合、通常、ビジネス コンポーネント、データベース コンポーネント (DAO として実装される可能性があります)、および UI コンポーネントになります。ビジネス ロジック コンポーネントは、アプリケーションの背後にあるコア ビジネス ルールを実施する役割を担います。データにアクセスし、データ操作のルールを適用するためのデータベース コンポーネント。最後に、ユーザーとの対話を制御するための UI コンポーネントです。

このような設計では、データベース コンポーネントにロジックを含める必要があるかどうかについての議論はありません。もちろん、ロジックを含める必要があります。データの保存、取得、解釈の方法を管理するルールが必要です。ただし、含まれるロジックの種類は、ビジネス ロジックまたは UI ロジックとは異なります。また、既に指摘したように、データベース コンポーネントはソフトウェア コンポーネントである必要はありません。データベース内のストアドプロシージャ、関数、およびトリガーで構成されている場合があります。

肝心なのは、DAO にロジックを自由に配置してかまいませんが、そのようなロジックがデータ アクセスに関連する操作にのみ関連することを確認してください。同様に、ユーザーとの対話を促進するロジックを UI コンポーネントに含めることも問題ありません。

于 2012-08-31T14:26:17.007 に答える
0

DAOが読み取る制限を定義できますBusinessObject1（例：1回しか更新できません）。次に、変更されたオブジェクトを DAO に渡し、その変更 (更新) を保持するように指示すると、DAO は例外をスローします。

これが Doctrine (Data Mapper ORM) の仕組みだと思います。

于 2012-08-31T10:41:03.127 に答える