SSHの中のStrutsはとてもささくれそうです.

SSHベースのアーキテクチャにおいて、基本的な流れはこうである.
 
1、展示層はstrutsでデータを収集する
2、actionでサービス層業務インターフェースを呼び出し、業務ロジック処理を実現する.
 
(ここで言うのはstruts 1です.)
 
このような過程において常に以下のような問題が存在する.
-------------------------------------------
 
1、struts actionは貧血になります.
 
     業務ロジックの後置によって、actionを使って実際の利益をもたらさず、かえってインタラクティブな一環を増やしました.典型的なactionはmapping dispatchモードを使用しています.各action方法は3行のコードしかありません.
 
 

    /**
     *      ,       
     */
    public ActionForward getFunctionTree(ActionMapping mapping, ActionForm form,
                                         HttpServletRequest request, HttpServletResponse response) throws StaffException {
        Collection tree = helper.getFunctionRootTree();
        request.setAttribute("tree", tree);
        return mapping.findForward("tree");
    }

 

    public ActionForward getRoles(ActionMapping mapping, ActionForm form,
                                  HttpServletRequest request, HttpServletResponse response)
            throws StaffException {

        Collection roles = helper.getAllRoles();
        request.setAttribute("roles", roles);
        return (mapping.findForward("success"));
    }

 
 
 
2、struts actionformも貧血で粒度が把握しにくいです.
 
    formにおける属性は、しばしば業務層のModelオブジェクトと類似性があるので、formにmodelの参照を定義するのが一般的な方法である.
 

import com.surekam.platform.staff.model.Department;
import org.apache.struts.action.ActionForm;

public class DeptForm extends ActionForm {

    /**
     *     
     */
    private Department department = new Department();

    public Department getDepartment() {
        return department;
    }

    public void setDepartment(Department department) {
        this.department = department;
    }

}

 
このようにすれば、フォームの価値はどこにありますか? 唯一の必要性はおそらくstrutsのフォームラベルの要求にformが必要です.
 
また、実戦では、formの数を節約するために、複数の操作でformクラスを共有することがよくあります.結果として、formは完全に大きなおでんになり、全く読めません.
 
 
-----------------------------------------
 
 
これはアーキテクチャの観点から明らかに共通性の問題である.皆さんのご意見を参考にして、実戦での経験を共有し、解決策を検討してください.
 
私達の解決方法はstrutsに対して一定のカプセル化と拡張を行っています.いわゆるNice Strutsのコンポーネントがこの問題を解決します.後で具体的に実現します.
ENDING----------------------------------------------------------------------------
 
招待状はみんなは多く帰って、ニワトリのあばら骨の問題に関して私はみんながここまで討論すると思って、へへ!
 
このスレッドの目的は、オープンソースコンポーネントとセットが実戦的に私たちが望む「アプリケーション層アーキテクチャ」との間の不協和を引き起こし、アーキテクチャ実践の中で、strutsだけを例にとって、strutsではなく、多くのことを考えることです.
 
 
事実:鶏の脇腹の実はstrutsではありませんて、私達は自分で検討します!
 
次のスレッドを参照してください.みなさん、引き続き卵を歓迎します.iframe>
 
http://www.iteye.com/topic/396024