著者：CodeSheepの
リンクします。https：//www.jianshu.com/p/fd99bebeadea
出典：ジェーンの本は
、著者が著作権を保有しています。著者は認可商業転載してください接触、非商用の転載は、ソースを明記してください。
この記事は非常によく、将来のプロジェクトのディレクトリ構造を設計する際の基準は、製造することができる、簡単に見つけることが、オーバー再現され、書かれています。
なぜ私はこれを書くのですか
最近、多くの初心者、ジュニアパートナーやSpring春ブーツ私的な手紙には、階層化プロジェクトのディレクトリ構造と符号分割に関する質問を交換しました。
パートナー、プロジェクト構造を読み、非常に孟あなたのコードを見て層、他の人のプロジェクトを学び、吸収するアイデアの種類には分からないことができない多くの小さなオンラインダウンロードオープンソース・プロジェクトを表します。
さて、今日の後半に肝臓にこの記事をアップ滞在し、誰もが交流を探求するために協力する、小さなパートナーの不備を批判をしてください。
アリは、合意された方法での最初の外観です
私は印象を持って、前に見たとき、「アリ・ババのJava開発マニュアル」、私は確かにそこに見に背を向け、およびので、階層的に関連する構造およびアプリケーションエンジニアリングの詳細を持っているようです。
これは、内容についておそらくこれこれです：の一種で、通常のビジネスのプロジェクトに共通のプロジェクト構造と符号分割レベルの指導。
押して、一般的に次の層に分割されている本の中で言いました：
- オープン・インタフェースレイヤ
- ターミナル表示層
- ウェブ層
- サービス層
- レイヤマネージャ
- DAO 层
- 外部インターフェースまたはサードパーティプラットフォーム
本の中のスペースの不足、推定初心者はまだ無知だったと、この場所は、より一般的で、それを置くので、次の実際のプロジェクトコードの構造びびり特定のプロジェクトをおしゃべりするには、構造とコードをレイヤード。
通常のプロジェクト構造
最初の前にあるものすべての：このことは、共通の標準を持っていない、さまざまな企業やチームの習慣や規範は同じではありません。
私たちは、3層にブーツは、例えば、分割する必要があり、全体的なプロジェクトから作成された非常に熱い春の典型的なプロジェクト構造を提示する必要があります。
项目根目录/src/main/java：場所プロジェクトJavaソースコード项目根目录/src/main/resources：置き、プロジェクトの静的リソースと設定ファイル项目根目录/src/test/java：コードのテストプロジェクトを配置
位置/src/main/java私たちは、より懸念しているJavaのソースコードディレクトリの組織構造は、この場所は、通常は、すべての後に、別のプロジェクトやチームが、同じ若干異なるが、全体的な取り決めを約あるべき練習をしていない、典型的な構造を与えられています。そしてあればモジュール複数のプロジェクト、その後、唯一のモジュールは、他のモジュールのコードの組織も実質的に同様であることを特徴とする請求以下の構造に対応しなければなりません。
各ディレクトリの詳細：
|_annotation：放置项目自定义注解
|_aspect：放置切面代码
|_config：放置配置类
|_constant：放置常量、枚举等定义
|__consist：存放常量定义 |__enums：存放枚举定义 |_controller：放置控制器代码 |_filter：放置一些过滤、拦截相关的代码 |_mapper：放置数据访问层代码接口 |_model：放置数据模型代码 |__entity：放置数据库实体对象定义 |__dto：存放数据传输对象定义 |__vo：存放显示层对象定义 |_service：放置具体的业务逻辑代码（接口和实现分离） |__intf：存放业务逻辑接口定义 |__impl：存放业务逻辑实际实现 |_utils：放置工具类和辅助代码 そして、次の/src/main/resources静的ページの静的リソースの設定ファイルや他のものの主記憶装置であるディレクトリ：
|_mapper：存放mybatis的XML映射文件（如果是mybatis项目）
|_static：存放网页静态资源，比如下面的js/css/img
|__js： |__css： |__img： |__font： |__等等 |_template：存放网页模板，比如thymeleaf/freemarker模板等 |__header |__sidebar |__bottom |__XXX.html等等 |_application.yml 基本配置文件 |_application-dev.yml 开发环境配置文件 |_application-test.yml 测试环境配置文件 |_application-prod.yml 生产环境配置文件 もちろん、この場所を持っていると推定されている多くの人々がもつれます上DTO/VO/DOやその他のデータモデルの定義を区別します。
dは、いわゆる厳密に区別をしたこの「マニュアルアリババのJava Development」 'は、本は定義することです。
DO（Data Object）：上方輸送層DAOデータソースオブジェクトを介してデータベーステーブル構造の一つの対応、。DTO（Data Transfer Object）：オブジェクトのデータ転送オブジェクト、サービスマネージャ、または外側に送信。BO（Business Object）：ビジネスオブジェクト。Serviceオブジェクトによってカプセル化ビジネスロジック層出力。AO（Application Object）：Applicationオブジェクト。Webおよびサービス層の間の層を多重化する抽象オブジェクト・モデルでは、非常に近いプレゼンテーション層に、再利用性は高くありません。VO（View Object）：表示層オブジェクト、送信レイヤテンプレートオブジェクトに対して通常はWebレンダリングエンジン。Query：クエリオブジェクトデータ、上位レイヤを受信するクエリ要求。注つ以上のパラメータクエリパッケージという、送信Mapクラスの使用を禁止。
正直に言うと、オブジェクトのように多くの定義を見て、私も非常にモンゴルいます。実際のプロジェクト開発、私は意図的に必要がないと考え、その後のオブジェクトは変換作業が人々のクローナを気にすることができませんので、ということなので、多くの層を定義するためのオブジェクトをコピーしてください。
簡単にするために、私が個人的に長いビジネスロジック層のように、感じるServiceとデータベースDAOない浸潤は、無混合しないことを確実にするために、互いの外動作オブジェクト厳密分割の層、問題は大きくてはなりません。
例えば、プロジェクトのコード構造上の実施例Iにおいて、Serviceターゲット層は、処理中に定義されているdto袋、及びDAOオブジェクトがレイヤ処理中に配置されるentity袋A。
プロジェクト構造割っ概要
これは、プロジェクトの構造を分析するために、上記のコードに対応するユーザの観点から、Webサイトを参照してください場合は、コード全体を積層することができます。
ディレクトリに対応する転送ロジック・コードは次のとおりです。
私たちは今より明確に表示されるはず、と思います。
だから、毎回の後、私たちは長い間、他の人がこのアイデアに基づいてプロジェクトのコードを参照すると、基本的に、処理に沿って得ることができる必要があり、手で新しいプロジェクトを取得します。
いくつかの注意
1は、Contorller渡すパラメータ層が推奨されていないHashMap、データモデルの定義を使用することをお勧めします
2、Controller層パラメータは、例外がスローされると、他の操作され、チェックに行うことができますが、に可能な限りとしてあまりにも多くのビジネスロジック、ビジネス・ロジックを入れていないお勧めしますService実行するコードの層
図3に示すように、Service層が実際のビジネス・ロジックを実行し、に応じて区別することができる十分に定義されており、機能モジュールは、お互いを呼び出すことができ
図4に示すように、機能モジュールService間の参照は、中に浸透しないことが推奨されるDAO層（またはmapperに基づいて、層）Serviceコールとリユースより合理的なレベル
5、ビジネスロジックServiceとデータベースDAO操作が混在していない層のオブジェクト。Controllerデータオブジェクトに直接層に浸透しないDAO層（又はmapper層）;同様に、エンティティ・オブジェクト・データ・テーブルをEntity直接通過しないControllerレベルの出力又はディスプレイ。