Java EE環境のエンティティBeanは貧血と見なされることを通知するいくつかの記事を読みました(動作を実装せずにゲッターとセッターのみを含むことを意味します)。
動作をエンティティBeanに入れるのを妨げるものは何ですか?セッションBean(ステートレスまたはステートフル)がすべてのビジネスロジックをそれらに委任できるようにするため(ロジックがエンティティによって所有されることを意味するため)。
エンティティBeanが必ずしも貧血である理由がわかりません。
Java EE環境のエンティティBeanは貧血と見なされることを通知するいくつかの記事を読みました(動作を実装せずにゲッターとセッターのみを含むことを意味します)。
動作をエンティティBeanに入れるのを妨げるものは何ですか?セッションBean(ステートレスまたはステートフル)がすべてのビジネスロジックをそれらに委任できるようにするため(ロジックがエンティティによって所有されることを意味するため)。
エンティティBeanが必ずしも貧血である理由がわかりません。
純粋なセマンティックの観点からは、ENTITYBeanはエンティティとその属性の表現であることが期待されます。これをいくつかのロジックと組み合わせると、エンティティクラスに追加の責任が追加されます。そして、カーリーの法則または単一責任の原則からわかるように、各クラスは1つのことと1つのことだけを行う必要があります。
http://www.codinghorror.com/blog/2007/03/curlys-law-do-one-thing.html
http://en.wikipedia.org/wiki/Single_responsibility_principle
この原則に違反する十分な理由があると信じる場合は可能ですが、私の経験では、特に私のようにソフトウェアの品質を信じる場合は、標準的なソフトウェアエンジニアリングの慣行に違反するほど強い理由はありません。コードの品質によって最もよく表されます。
エンティティBeanに機能を実装する際の制限はありませんが、アプリケーション全体で使用することを意図したものではないため、ほとんどの場合、Session Beanにアクセスする必要があるという理由だけで、SessionBeanのエンティティを変更する動作を追加します。たとえば、フロントエンド。
さらに深く掘り下げると、セッションBeanメソッドは通常、トランザクションとセキュリティの側面で装飾されていますが、エンティティBeanはそうではないため、エンティティにコードを追加した場合、アプリケーションは期待どおりに動作しない可能性があります。