web-dev-qa-db-ja.com

Angularプロジェクト構造のベストプラクティス

誰かが私のプロジェクト構造について何か提案をしてくれませんか？

-app
  -layout
     -home-layout
         -header
         -menu
         -content
            -detail-page
               -left-side
                  -left-side.component.html
                  -left-side.component.ts
               -right-side
             -detail-page.component.html
             -detail-page.component.ts
         -footer
     -pipes
     -widget-features
  -material-module
  -services
  -models

実際の構造では、サイトマップの編成は非常に巧妙で、さまざまなページのコンテンツを簡単に見つけることができます。しかし、モジュラーアーキテクチャを取得するには、構造を再編成したいと思います。アドバイスをお願いします。

ありがとうございました。

angulartypescriptmodular-design
8
pierre

このための魔法の弾丸や、すべてのプロジェクトに適合する一般的なレシピはありません。

つまり、公式の Angular Style Guide を使用できます。これは Folders-by-feature構造 を追跡しようとします。

アプリケーション構造に関して [〜＃〜] lift [〜＃〜] ：

[〜＃〜] l [〜＃〜]コードをすばやく配置できるようにアプリを構造化してください、[〜＃〜] i [〜＃〜]コードを一目で識別し、[〜＃〜] f [〜＃〜]最新の構造を維持し、[〜＃〜] t [〜＃〜]ry to DRY

  • [〜＃〜] l [〜＃〜]ocate

直感的でシンプルかつ高速なコードの検索を行います。

  • [〜＃〜] i [〜＃〜]dentify

ファイルに何が含まれ、何を表しているかがすぐにわかるように、ファイルに名前を付けてください。

ファイル名を説明し、ファイルの内容を正確に1つのコンポーネントに保持してください。

複数のコンポーネント、複数のサービス、またはそれらが混在するファイルは避けてください。

  • [〜＃〜] f [〜＃〜]lat

可能な限りフラットなフォルダー構造を維持してください。

フォルダーが7つ以上のファイルに達したときにサブフォルダーを作成することを検討してください。

IDEを構成して、生成された.jsファイルや.js.mapファイルなどの気が散る、無関係なファイルを隠すようにしてください。

  • [〜＃〜] t [〜＃〜]ryを乾燥させる

DRY（自分自身を繰り返さないでください）。

DRY読みやすさを犠牲にすることは避けてください。

示した構造によると、確認する価値があるかもしれないことの1つは、原則Do keep a flat folder structure as long as possible。

これは、構造を可能な限りフラットに保つ必要があることを意味します。これにより、ファイルをすばやく見つけることができます。しかし、これはmustルールではなく、shouldルールです。そのため、構造をよりフラットにしても、現在の論理的な組織に影響しない場合は、おそらくフラットにする必要があります（そうでなければ、フラットにする必要はありません）。

覚えておいてくださいこれは開発プロセスを改善することを目的としています：チームの組織/生産性などが改善されない場合は、使用しないでください。

8
lealceldeiro

Angular Style Guide が依存するアーキテクチャは、「機能モジュール」アーキテクチャとして知られ、機能はAngularモジュール（@ngModuleデコレータを持つTypeScriptクラス）。

感触をつかむには、Angular CLIを使用していくつかの生成コマンドを実行してみてください。

たとえば、カプセル化されたコンポーネント/サービスを含む機能モジュールを作成するには、次のコマンドを順番に実行します。

ng g m my-awesome-feature
ng g c my-awesome-feature/cool-component
ng g s my-awesome-feature/fancy-service

CLIはNiceモジュールアーキテクチャを作成し、モジュールファイルでコンポーネントを自動的に宣言します！

import { NgModule } from '@angular/core';
import { CommonModule } from '@angular/common';
import { CoolComponentComponent } from './cool-component/cool-component.component';

@NgModule({
  imports: [
    CommonModule
  ],
  declarations: [CoolComponentComponent]
})
export class MyAwesomeFeatureModule { }
6
hevans900

私の意見では、URLベースの構造とモジュラーアーキテクチャのベストを組み合わせた同様の構造を常に使用しています。次のようなものです。

  • アプリ
    • _models
    • _services
    • _shared
      • 共有コンポーネント
      • 共有モジュール
    • ホーム
    • どんなページ
      • 特定のコンポーネントは何でも

基本的に、「_ shared」には、フッターやマテリアルモジュールなど、異なるページ間で共有されるすべてのコンポーネントとモジュールを配置します。それらを宣言するか、_sharedモジュールでインポートし、エクスポートする必要があります。

すべてのサービスはアプリモジュールで共有および提供されるものと想定していますが、もちろんそれらを_sharedモジュールまたは他の子のモジュールに配置することもできます。

ちなみに、エクスプローラーに表示されるように、実際のアンダースコアで名前を付けます。彼らがいつもそこにいることを知るのは便利です。

1
RTYX