1) 技術的には、ビジネス オブジェクトとビジネス エンティティ (または「エンティティ オブジェクト」と呼ぶ場合) は同じではありません。
ビジネス エンティティにはデータが含まれます。一方、ビジネス オブジェクトには、ビジネス エンティティに関するロジック (エンティティの作成方法、エンティティの更新方法など) が含まれています。ビジネス オブジェクトは、技術的には古い J2EE パターンです。現在のコードでは実際に見たことがないので、詳細を説明することはできません。ビジネス オブジェクトは DAO に対応すると言う人もいれば、むしろサービスと言う人もいます。また、一部の開発者は、「オブジェクト」と「エンティティ」の粒度が同じであると考えているため、またはビジネス エンティティにもロジックが含まれているため、または単に知らないという理由で、ビジネス オブジェクトとエンティティが同じであると言っています。私は、データを含むオブジェクトの「(ビジネス) エンティティ」について話したいだけであり、「ビジネス オブジェクト」という用語は、異なる解釈をする可能性があるため、決して使用しません。
2) Spring MVC のドキュメントによると、コマンド オブジェクトは、フォームからのデータが入力される JavaBean です。一方、フォーム オブジェクトとは何ですか。
そうです、コマンド オブジェクトは意味的にはフォーム オブジェクトと同じです。私はすぐに理解できるフォームオブジェクトという用語を好みます。
3)あなたが言ったように、Spring MVCのドキュメントによると、フレームワークの1つの機能は
再利用可能なビジネス コードで、複製の必要はありません。既存のビジネス オブジェクトをミラー化するのではなく、コマンドまたはフォーム オブジェクトとして使用して、特定のフレームワーク基本クラスを拡張します。
そうです、Spring によれば、コマンド/フォーム オブジェクトとしてビジネス エンティティを使用できます。納得できない場合は、いくつかの理由があります。
- 簡単にするために。そして、私たちの Java ソフトウェア アーキテクチャにはもっと単純さが必要であることを神は知っています。一部の企業は、非常に単純なことを行うのにレイヤーを使いすぎています。これに対抗するために、Spring、Java (以下を参照) などを中心に多くのイニシアチブが行われています。
- あなた自身のために、それはプログラミングをより簡単に、より簡単に、より面白くするからです
- Spring と Java (JSR を介して) がそう言っているからです。実際、フォーム オブジェクトに何を期待するのでしょうか。フォームのバッキングと、おそらくいくつかの検証。この検証をどのように行いますか? Spring MVC 3 は、JSR-303 @Valid アノテーションを使用した @Controller 入力の検証をサポートしています。検証する制約をどこに配置しますか? JSR-303 によると、これらの制約 (@NotNull、@Length など) を格納するのに最適な場所は、ビジネス エンティティ自体内です。結論: コマンド/フォーム オブジェクトとしてビジネス エンティティを使用することをお勧めします。
- 関心の分離は引き続き尊重されます。1 つの懸念事項 (フォーム バッキング) が、もはや懸念事項ではないというだけです。Spring MVC がそれを処理します。:-) ビジネスエンティティについて心配するだけです。