私が従う一般的なルールは、トランザクション境界がサービスBeanでマークされているため、トランザクションがすでに実行されているかどうかわからないため、サービスの外部で休止状態のPOJOを変更することは好きではありません。したがって、バッキングBeanから、サービスレイヤーが休止状態のpojoを構築して保存、更新などするために必要なパラメーターをサービスレイヤーパスと呼びます。
これを行う別の方法は、バッキングBeanにサービス層によって定義されたインターフェースを実装させてから、バッキングBeanをサービス層に渡すことです。例えば。
public interface UserInfoRequest {
public String getName();
}
@Service
public class SomeSpringService {
@Transactional(.....)
public void registerNewUser(UserInfoRequest request)
{
}
}
public class SomeBackingBean implements UserInfoRequest {
private SomeService someSpringService;
public void someMethodBoundToSJF()
{
this.someSpringService.registerNewUser(this);
}
}
最後の質問ですが、私はJSFのファンではありませんが、JSFはサーバーコンポーネントベースのフレームワークであるため、根本的に欠陥があると思います。したがって、JSFに対する私の議論は、サーバー側のコンポーネントベースのフレームワークに対する一般的な議論です。
サーバー側のコンポーネントベースのフレームワークの主な欠点は、コンポーネントの出力を制御できないことです。つまり、コンポーネントの外観に固執します。外観が異なるものが必要な場合は、独自のコンポーネントを作成する必要があります。既存のコンポーネントを変更します。Webブラウザーは現在、アプリケーションUIの品質を実際に向上させることができる新機能を追加することで非常に急速に進化していますが、これらの機能にはHTML、CSS、およびJavaScriptを直接記述しなければならず、サーバー側のコンポーネントはそれを難しくします。
クライアント側のコンポーネントアーキテクチャはここにあり、サーバー側でコンポーネントを実行するよりもはるかに優れています。これが私のおすすめのスタックです。
クライアント側のアーキテクチャ：
- jquery.js-すべてのブラウザをJavaScriptと同じように見せるための基本的なライブラリ
- backback.js+underscore.js-高レベルのクライアント側コンポーネントベースのアーキテクチャ
- handlebars.js-クライアント側テンプレート用
- Twitterブートストラップ-CSSとウィジェットのまともなスターターセットを取得する
AJAXを使用してサーバー側モデルと通信するバックボーンビューとして編成されたHTML、CSS、およびJavaScriptでコードを記述します。再利用可能なコードを実際に作成するのに十分な構造で、クライアント側のユーザーエクスペリエンスを完全に制御できます。
サーバーサイドアーキテクチャ：
- アノテーション駆動型SpringMVC、サービス、およびDao（@ Controller、@ Service、@ Repository）
- タイプ別の自動配線によるスプリングコンポーネントスキャン（@ Autowired、@ Inject）
- AspectJロードタイムウィービングまたはコンパイルタイムウィービング
- Hibernate
- Tomcat 7
- Spring MVCのビューテクノロジーとしてのJSP（はい、それは不格好ですが、ほとんどの場合、usng <％@inculde>ディレクティブの場合はあまり多くのjspページを作成することはありません
ツール：-Springツールスイート-JRebel（サーバーを起動および停止する必要がないように）それは本当にお金の価値があります-Tomcat 7