6

私たちはかなりコードの多い PHP5 プロジェクトに取り組んでおり、先週は RESTful API の PoC に取り組みました。モデルクラスをビジネスクラスから分離しています。

CRUD 機能を実装しようとすると、モデルに対して CRUD を直接実装するのは非常に簡単ですが、ビジネス ロジックに対して CRUD を実装するのは簡単ではありません。その機能は現在存在するビューに固有のものであり、そのインターフェイスは提供しないためです。 API を実装するために必要な一般的なデータ アクセス モデル。

このことについて考えてみると、次のような疑問が頭に浮かびました。

  • モデルの柔軟性を維持し、モデルが現時点で気にしない機能を維持しながら、データを操作するための最良の方法は何ですか (電子メール アドレスを変更するときにアクティベーション リンクを含むメールを送信するなど)。

  • ビジネスロジックのほとんどがモデルに実装されている以前にdjangoで多くの作業を行ってきましたが、ビジネスロジックを分離しておく必要があるのはなぜですか? 実際の例はありますか？もしあれば、これはどのような問題を解決しますか?

いくつかの可能な解決策も頭に浮かびました：

  • ビジネスロジック全体をモデルに入れます。save メソッドの呼び出し後または呼び出し前に、どのフィールドが変更されたかを確認します。
  • オブザーバー パターンを使用してビジネス オブジェクトにモデルの変更を通知し、モデルと直接やり取りします。

あなたの意見では、長所と短所は何ですか、どうしますか?

4

1 に答える 1

2

データのストレージをデータ アクセス レイヤーで分離すると、必要な分離とモデルの機能が得られます。

DAL (doing queries etc)
  |
Model (doing business)
  |
Controller
  |
View

したがって、ビューにはアクションがあります: 支払い済みとしてマークします。したがって、コントローラーはリクエスト (POST) /invoice/1/markaspaid (または使用するその他の URL 構造) を取得します。次に、コントローラーがモデルを呼び出します。

$Invoice=new Invoice();
$Invoice->markAsPaid(1);

次に、モデルは DAL を呼び出して、この変更を実際に保存します。これをモデルから分離する必要はありません。非常に複雑または非常にトランザクションが多い場合は、複雑なタスク用に別のサービスを検討することもできます。そうすれば、モデルが薄くなり、複雑なパーツが分離されます。

モデルの柔軟性を維持し、現時点でモデルが気にしない機能を維持しながら、データを操作するための最良の方法は何ですか (電子メール アドレスを変更するときにアクティベーション リンクを含むメールを送信するなど)。

私はこれを完全に理解していません。私が見る限り、電子メールの送信プロセスは通常のコード実行から分離する必要があります。だからそれをキューに入れて、そこに見つけてください。通常のコード パスの一部ではありません。モデルから開始することもできますが、それだけです。

そのトピックに関連する情報があるこの質問を参照してください: Cakephp cron job to call a controller's action

于 2012-07-21T11:24:11.910 に答える