はどのようにビジネスロジックを実行するJavaクラスからのStruts Actionクラスを分離するための支柱フレームワークとデリゲートパターンを使用することができますか?Strutsとの委任パターン
0
A
答えて
0
さて、(例えば、ユーザを迎える)、あなたには、いくつかの商務ロジックを作るインターフェースを持っているとしましょう:
IBussinessLogic
public interface IBussinessLogic{
public void greetUser(String username);
}
そして、あなたはそのインターフェイスを実装するクラスを使用します。
BussinessLogic
public class BussinessLogic implements IBussinessLogic{
public void greetUser(String username) {
System.out.println("Hello " + username + ".");
}
}
次に、あなたのアクションクラスであなたが委任することができ、無申し訳ありませんが、あなたはあなたの商務・ロジック・クラスのデリゲートする必要があります。前方に戻って、制御フロー:
...
IBussinessLogic bl = new BussinessLogic();
bl.greetUser(myForm.getUsername());
...
アクションは、いくつかのresponsabilitiesを持って、覚えておいてください。 ..しかしそれらのどれもあなたのアプリケーションのビジネスロジックを実装する必要はありません。インターフェースを使用することで、依存関係注入やその他の技術を使用していても、今後IBussinessLogicのさまざまな実装でアプリケーションを再配線できます。
これは、デリゲートパターンの非常に簡単な例です。あなたの行動(委任者)は、タスクを達成するために代理人(BussinessLogic)を信頼します。
関連する問題
- 1. 戦略パターンと委任パターンの違い
- 2. 委任パターンと間接パターンの違い
- 3. Swift:プロトコルと委任パターンについて
- 4. Javaの委任パターンについて
- 5. ビューコントローラの委任と解任
- 6. のLogonUserと委任
- 7. 委任とデータソースiOS
- 8. Java Mockitoと委任
- 9. 継承と委任
- 10. 委任
- 11. サブドメインの委任
- 12. サービスクラス委任
- 13. NSViewController委任
- 14. Googleサービスアカウント委任
- 15. 委任 - C#
- 16. ラムダ委任
- 17. 委任サブドメインは
- 18. FIRMessaging委任エラー
- 19. 委任モード:PARENT_FIRST
- 20. 拡張委任
- 21. C++での委任
- 22. NSPersistentDocumentアプリの委任
- 23. クラッシュWebViewの委任
- 24. が委任属性
- 25. クラス間委任 - ベストプラクティス
- 26. 委譲パターン用UML
- 27. ビューの変更とイベントリスナーの委任
- 28. カスタムオブジェクト/ライブラリへのリクエストのインターセプトと委任
- 29. メソッドの委任とフィールドの追加
- 30. Swiftのシングルトンクラスの委任
私はそれらについて尋ねる問題に持っています。まず、デリゲートパターンとファサードパターンの違いは何ですか?二Strutsアクションクラス内のファサードを使用するための良い方法は何か、私は私のファサードは、より汎用的にすることができますどのように私は何かをする事業にリクエストからパラメータを渡す必要があるStrutsアクションクラス内を意味します。 –
デリゲートパターンを使用すると、異なる層に責任を分けることができます。 bussinessロジックを別のレイヤーにするのは良い設計戦略です。要求オブジェクトをbussinessロジックレイヤーに送るのは悪い決断です。あなたがそうするなら、bussinessレイヤーをあなたのウェブインターフェースに結びつけています。今後、スイングインターフェイスなどのアプリケーションを再利用することはできません。 ファサードパターンを使用すると、ソフトウェアライブラリ/パッケージへのアクセスを容易にすることができます。元のライブラリ/パッケージよりも複雑さの少ないインターフェースを実装しています。 – JML