2

Web フレームワークは常に、優れた OO コードから離れているようです (コードとデータをオブジェクトにグループ化し、そのオブジェクトにメッセージを送信するという観点から考えるなど)。

主な問題は、Bean パターンの存在のようです。データベース、Web サービス、およびその他のほとんどのものと対話するために、Bean パターン (人々は違いを理解していないように見えるため、最近は POJO と呼ばれることが多い) を使用します。

したがって、コードなしでセッターとゲッターのこのボールに行き詰まっているわけではありません. オブジェクト指向コードのほとんどすべての利点がなくなりました。

私が検討している 3 つの解決策がありますが、それらのいずれかに重大な欠点があるかどうかを知りたいと思っていました。

1) Bean パターンの代わりに POJO パターンを使用します。これは、POJO からセッターとゲッターを削除し (カプセル化/データの安全性を確保できるようにするため)、代わりにビジネス ロジック メソッドを追加することを意味します。これは最も理にかなっているように思えます。実際、休止状態のようなライブラリが Bean を要求することから POJO を許可するように切り替えた理由だと思いますが、それでも誰もが代わりに Bean パターンを使用しているようです。

2) Bean のフィールドをストレージとして使用するビジネス ロジック クラスで Bean を拡張します。これは不安定で問題があるように見えますが、移行する方法として既存のコードベースにドロップするのは非常に簡単です...

3) Bean パターン オブジェクトをビジネス ロジック オブジェクトでラップします。＃1が本当に問題がある場合、これが必要になる可能性があると思います。

私が最も疑問に思っているのは、なぜ #1 が使用されているのを見たことがないのかということです。休止状態のオブジェクトに Pojo パターン (ビジネス ロジックを使用し、セッターとゲッターを使用しない) を使用し、それに問題があった (または非常にうまく機能した) 人からの連絡をお待ちしています...

4

6 に答える 6

3

コメントを回答に変更します。私は基本的にあなたの最初の前提に同意しません

Webフレームワークは、常に優れたオブジェクト指向コードから離れているようです。

JavaEEまたはSpring/JPAモデルには、「優れたOOコードから離れる」ものはありません。hibernateのようなJPAプロバイダーがPOJOを許可しているという事実は、Beanのビジネスロジックを定義するリッチドメインモデルを使用できないことを意味するわけではありません。Java Webアプリの場合、私はそれが両方の方法で行われるのを見てきました。リッチドメインモデル、またはサービスレイヤーにビジネスロジックを備えたアネミックドメインモデルです。これは、OO以外または悪い設計である必要はありません。

おそらくあなたが言っているのは、多くのアプリが適切なデザインや適切なOOで書かれていないということだと思います。 私が同意すること。しかし、それはフレームワークとは何の関係もありません。

したがって、提案されたソリューションはすべて、基本的に「優れたOO原則を使用してアプリケーションを適切に設計する」と言っています。オプション1が最も簡単です。

于 2012-10-10T20:15:34.887 に答える
1

人々はBeanを「POJO」と呼ぶ傾向があると言っているので、Beanを使用する代わりに「POJO」を使用することをお勧めします。しかし、この点に答えるには：

したがって、コードのないセッターとゲッターのこのボールに行き詰まっているわけではありません. オブジェクト指向コードのほとんどすべての利点がなくなりました。

私はこれに同意しません。オブジェクトを操作する静的関数を作成している場合、設計に何か問題があります。

通常、一般的な「ベスト」プラクティスは、ビジネス ロジックをクラスの「サービス レイヤー」にラップすることです。このクラスは、データ (Bean、POJO、ドメイン オブジェクトなど、呼びたいものは何でも) を操作する方法を知っています。アプリケーションのルールに。

サブクラスや継承などを使用して、「サービスレイヤー」をオブジェクト指向で設計することを誰も止めません。

Employee通常、データを保持するクラスに、 で操作を実行するメソッドとロジックも含まれているアプリケーションを構築する人はいません。これは、データ (クラスEmployeeによって表される) をロジックから分離したい傾向があるためです。Employeeまた、実際には、クラス内の従業員インスタンスで動作するメソッドを作成し始めると、クラスがストレージ層自体を呼び出すことができるようにEmployeeする必要があり、 Hibernate を使用して結果を表すクラスが必要になります。Employeeクエリ (Employeeクラス) には、それ自体をロードするための Hibernate コードへの参照もあり、非常に混乱します。

あなたが目にする「問題」は、これらのタイプのアプリケーションに共通する設計思想との意見の相違に過ぎないと思います。ほとんどの人は、アプリケーションのロジックをカプセル化するコードからデータの表現方法を分離したいと考えています。

于 2012-10-10T20:25:33.367 に答える
1

ビジネス ロジック (のほとんど) をデータ オブジェクトの外部に保持するのには十分な理由がありますが、最適な設計には、データ オブジェクトの特定の部分が含まれます。これを正すのは簡単ではありません。特にブルーカラーのチーム環境では、Java 開発チーム全体の 95% がそうだと思います。

私は、シンプルで自己完結型で広く再利用可能なロジックの断片をデータ オブジェクトに入れるのが好きです。特定のビジネス要求に関係なく、そのデータに本質的に結合されているコード。例は、いくつかの変換、検証などです。

ゲッターとセッターに関しては、私は絶対に避けています。public final フィールドを使用することも、単純な public フィールドを使用することもできます。ゲッターとセッターの組み合わせは、パブリック フィールドとまったく同じカプセル化を提供します: ゼロです。

ORM ソリューションに関しては、私は Hibernate を厳密に SQL の利便性のために使用しており、永続的な状態マネージャーとしては使用していません。マップされたクラスは、XML マッピングの代わりとしてのみ存在します。読み取り操作でインスタンス化されることさえありません。挿入の場合、各オブジェクトを個別に保存します。これにより、推移的な永続性を持たずに、1 つのデータベース行に 1 対 1 でマップされます。これは基本的に、私の Hibernate モデル オブジェクトが、データベースの行を Java で見る方法にすぎないことを意味します (さらに、便利な結合列の仕様 — HQL は冗長な結合基準がなくても見栄えがよくなります)。

于 2012-10-10T21:16:04.913 に答える
0

ベストプラクティスに従って、ビジネスロジックはプレゼンテーションロジックから分離する必要があります。ほとんどのWebフレームワークは、データの表示に関する優れた機能を提供します。データの取得/操作に関連するビジネスロジックは、とBusiness Layerの間の追加レイヤーである、で記述する必要がpresentation layerありdata layerます。オブジェクトはとPOJOの間のデータキャリアとして動作します。アクセサメソッドとしての属性を持つ非常に軽いオブジェクトであるため、これには非常に適しています。Business LayerPresentation LayerPOJO

残りはあなた次第です。ビジネスロジックを含む複雑なBeanオブジェクトを使用したい場合、Webフレームワークがそれを妨げることはないと思います。

お役に立てれば。

于 2012-10-10T20:18:09.643 に答える
0

おそらく、他のKnockout（javascriptフレームワーク）の中で使用されているModel-View-ViewModelデザインパターンを調べることができます。ここでは、ビューモデルがモデルとビューの間のレイヤーとして導入され、ビューをモデルから分離する可能性があります。

詳細については、こちらをご覧ください：http: //knockoutjs.com/documentation/observables.html..およびこちらhttp://en.wikipedia.org/wiki/Model_View_ViewModel

于 2012-10-10T21:01:05.487 に答える
0

「私が最も疑問に思っているのは、なぜ #1 が使用されているのを見たことがないのかということです。」関心の分離、単一責任の原則 (おそらく何よりも)、テスト可能性など。「すべてがすべてに結合されている」というモデルは便利ですが、客観的にはひどいものです。(これは、便利な API サーフェスが悪いと言っているわけではありませんが、代わりにではなく、適切にファクタリングされたテスト可能なコードの上に構築する必要があります。)

たとえば、ビジネスロジック層の上に「ダム」DTO層を追加すると、すべてのビューが、ビューを作成するために必要なすべてを含むBeanにマップされます。プロパティを取得するか、ORM をラングリングしてそれらを熱心にフェッチします。(前者は、データベースのラウンドトリップを増加させる N+1 選択の問題があることも意味します。)

また、すべてのリクエストが専用のサービス レイヤーでの単一のメソッド呼び出しによって処理される場合、トランザクション スコープの追跡が容易になります。この呼び出しは、データに対する単一の論理操作であるため、トランザクション処理の設定が簡単になります。

最後になりましたが、このアプローチは、理解しやすく、独自に変更しやすい小さなクラスにつながります。たとえば、成績平均点を計算するためのアルゴリズムを変更する必要がある場合、そこから開始しGradePointAverageCalculatorてそこからナビゲートする必要がある場合は、コードの範囲を確認する必要はありませStudent.javaん。

于 2012-10-10T20:22:51.520 に答える