多層アプリケーションを言えば、ほとんどの人は、これは非常に単純なことではないことに同意します
Controller、Service、Mapper3。実際には、多くの人々は、多くのコードでは、職務の彼らの分離を開いていない、シンプルなルックスControllerロジックよりも、やってServiceもより多くのServiceパススルーとして、多くの場合、これは多くの人々が、とにかく機能場所の開発コードを認識していない、実際にあります聖歌を置くこととは関係ない、使用することができます。これは、多くの場合、コードの後ろになり、階層混乱を再利用することができない、コードのフォローアップメンテナンスが非常に面倒です。
一、背景
良い多層アプリケーションでは、次のものが必要です。
- その後のメンテナンスコード拡張を容易にします。
- レイヤード効果が受け入れるようにチーム全体を取得する必要があります。
- 明確な責任の境界の各層。
第二に、どのように層状
2.1仕様アリ
アリエンコーディング仕様の制約は次の階層化：
- オープンインタフェース層：直接カプセル化
Service方法が露出するRPC。介してインターフェースをWeb中にカプセル化httpインターフェース、セキュリティ制御のためのゲートウェイおよびフロー制御。 - 端末表示層：テンプレート層展示レンダリングとそれぞれの端を実行します。
Web層：主にアクセス制御転送のために、基本的なパラメータのすべての種類を確認し、または再利用可能なビジネス簡単な処理ではありませんされています。Serviceレイヤ：相対特定のビジネス・ロジック・サービス層。Managerレイヤ：一般的なビジネスプロセス層、次の特徴があります。- パッケージ化され、サードパーティのプラットフォームの層、変換前の異常情報と結果を返します。
- 以下のための
Serviceそのようなキャッシング方式、一般的な処理ミドルウェアとしての機能の一般的な層を、沈没。 - そして
DAO層は、交互に複数あるDAO多重化の組み合わせが挙げられます。
DAO層：データアクセス層、基盤となるとMySQL、Oracle、PostgreSQLデータの相互作用。
アリババは、法令が比較的明確で単純明快ですが、説明がまだあまりにも簡単だった、と重ねService層とManager多くの学生との間の層の関係はまだ少しを伝えることができなかった、多くのプロジェクトにつながっていることはなかったManager層が存在します。ここでは、階層化されなければならないか、特定の企業です。
2.2、階層的最適化
それは私たちのビジネスの発展から、より理想的なモデルを要約したものです。
- トップ
ControllerとTService私たちの第一層の仕様アリは内部積層されている：光ビジネスロジック、パラメータの検証を、異常すべての詳細を明らかにしました。通常、このタイプのインタフェースはインタフェースの交換を容易に行うことができるので、ビジネスロジックは、光、さらには特定しませロジックでなければなりません。 Service：すべてのビジネス層、低再利用性、ここで推奨Controller方法は対応していたService、振り付けでビジネスを入れていないController行うことで、その理由は？我々は、ビジネスオーケストレーションに置く場合はController、将来的に、我々は他のフレームワークにアクセスしたい場合は、そうする層が、ここでは、ビジネスの配置で行う必要があり、これはそれぞれの層のためのエントリにアクセスするために私たちをリードするこのコードはする再コピーを持っていました下図のように：
作業の重複のような多くは確かに我々の開発の効率低下につながる、我々は、ビジネスロジックの振り付けを配置する必要が入れていたServiceそれを行うには中：
Mannager：再利用可能なロジック・レベル。ここではMannagerそれは我々がされているような、単一のサービスすることができCache、MQあなたが複数呼び出す必要があるときに、もちろん、複雑になる可能性がMannager倍に、そしてこれは一つに結合することができるMannagerようにしても、テーブル、クエリロジックとして、。あなたはしている場合httpMannagerやrpcMannager、いくつかのデータ変換を行うには、このレベルで必要になります。DAO：データベースアクセス層。「Javaオブジェクトにマッピングされたデータベースの特定のテーブルの操作は、」の責任Daoだけでその可能にするべきであるService他は、アクセスをService自分のデータにアクセスしたいが対応しなければなりませんService。
第三に、フィールドに階層モデル
3.1、ドメインモデルの法令をコーディングアリババ
DO（データオブジェクト）：によってデータベーステーブル構造の1対1の対応、DAO上向きのトランスポート層データ・ソース・オブジェクト。DTO（データ転送オブジェクト）：データ転送オブジェクト、ServiceまたはManagerオブジェクトのアウトバウンド送信。BO（ビジネスオブジェクト）：ビジネスオブジェクト。Serviceカプセル化するビジネスロジック層の出力オブジェクト。AO（アプリケーションオブジェクト）：アプリケーションオブジェクト。ではWebで層Serviceの多重層との間に抽象オブジェクト・モデル、プレゼンテーション層に非常に近い、再利用性は高くありません。VO（ビュー・オブジェクト）：表示層オブジェクトは、通常、Webテンプレートエンジン輸送層にオブジェクトをレンダリングします。Query：クエリオブジェクトデータ、上位レイヤを受信するクエリ要求。ことに注意してくださいつ以上のパラメータクエリパッケージは、使用禁止Mapに送信するクラスを。
| レベル | ドメインモデル |
|---|---|
| コントローラ/ TService | VO / DTO |
| サービス/ Mannager | AO / BO |
| DAO | 行う |
各レイヤは、ドメインモデルに対応する単一の要求で3回あるいは4つの変換を発生するため、対象物に導くため、独自のドメインモデルで、各層の追求の上に何人かの人々につながる、基本的には自分のしています、ときに、同じのリターンは3-4回の変換を発生しますので、フルを要求することが可能である - 多くの時間が変換オブジェクトが返されます。あなたが本当にそう従うなら、私はあなたが他の開発に書いていない怖いです、日の光がロジックのこの役に立たない繰り返しがそれを忘れて書きます。
3.2ので、私たちは妥協案を取らなければなりません。
- 可
Service/Managerこのレベルのデータ・ドメインモデルを操作することができ、それが彼らの仕事をしなければならないことは、ビジネスロジックとデータ処理アセンブリを行うことです Controller/TServiceドメインモデル層は、着信を許可しないDAOようにしない責任の分割に沿ったように、層。
同様に、許可されDAOたデータは、レイヤに渡さController/TService。
第四に、パッケージ名の命名について：
entity4.1、 model、、 domain最終的にどのように使用するには？
多くによると、Javaビューのプログラマの経験"ポイント、テーブルが対応するデータベースであるDomainオブジェクトは、非常に多くのプログラマが一度コードを書く、パッケージ名が使用されますcom.xxx.domain、書き込みは貿易の制限となっているようだ、データベースのマッピングオブジェクトそれはする必要がありますdomain。しかし、あなたは間違っている、domainドメインオブジェクトである、多くの場合、我々は、伝統的な行うJavaソフトウェアのWeb開発を、これらはdomain貧血のモデルです、何の行為や動作がないことをこの理論が関係しているとなるよう、十分なドメインモデルを持っていない、これらのdomainそれが普通である必要がありentityそうにパッケージ名を入れてください、オブジェクトではなく、ドメインオブジェクト：com.xxx.entity。
4.2、次の3つの言葉がまとめるentity、model、domain異なります：
entity：同じデータベースフィールドでなければなりませんmodel：私たちは何のフロントエンドを提供するために必要なものdomain：めったに使用されない、オブジェクトモジュールを表します
V.の概要
- 全体的なビジネスは、将来の再利用可能なコードかどうかを判断する、階層的なコーディング標準のためのより重要である明確な責任、明確な境界かどうか。
- もちろん、これは実際に重ね意見の問題である、すべてのチームの層状の習慣が異なる場合、それは標準のためのガイドラインを比較検討することは困難であり、一般的な業務は限り論理的、簡単にフォローアップするためのメンテナンスが良い成層です。