2

ここで説明したように、ユーザーのログイン情報を保存し、それを他の管理対象 Bean に正常に注入するための @SessionScoped ApplicationBean があります。

私も @ManagedProperty アノテーションで Dao インターフェイスを使っていますが、使い方に違和感があります。

public メソッド listStocks(String companyCode) を持つ StockDao があり、ユーザーのログイン時に companyCode が ApplicationBean に格納されているとします。

したがって、マネージド Bean はこのように DAO レイヤーを呼び出しています

@ManagedProperty(value = "#{appBean}")
ApplicationBean appBean;

public void getStockList() {    
    return stockDao.listStocks(appBean.getCompanyCode());       
}

これは、SQL が companyCode を必要とするすべての場所で繰り返されます。

私のDAOレイヤーがcompanyCodeを知っていれば（つまり、DAOにApplicationBeanを注入することを意味します）、以下のような方法を使用する方が良いと思います

public void getStockList() {    
    return stockDao.listStocks();       
}

問題は、どの API 設計が優れているかということです。2 番目に投票した場合、どのように @SessionScoped Bean を DAO レイヤーに挿入できますか?

4

2 に答える 2

2

DAO レイヤーではセッション変数を使用しません。ビジネス ロジックとユーザー インターフェイスの欠如がまさに DAO の原因です。つまり、データ アクセスを抽象化するだけのレイヤーです。

セッション依存の状態を追加すると、DAO レイヤーが DAAMUIS レイヤー (ユビキタスなData Access And Miscellaneous User Interface Stuffレイヤー) に変わります。私はDAAMUISが間違っている、または悪いと言っているのではなく、質問を言い換える必要があるというだけです.

于 2013-02-06T10:46:41.997 に答える
2

私にとって、最初のアプローチははるかにクリーンです。DAOレイヤーをセッションマネージドBeanと結び付けたくありません。

一般的なアーティファクト、特に daos とデータ モデルを、外部依存関係なしに別の Jar としてパッケージ化して保持します。このようにして、Web アプリ、スタンドアロン、または EJB のいずれであっても、変更を加えずに同じものを使用できます。

これにより、会社コードがどこからどのように取得されたかに関係なく、Dao を維持できます。

于 2013-02-06T10:31:42.747 に答える