タグ付けされた質問 「directory-structure」

ソースフォルダー階層に関してはsrc、コンテンツがわかりやすい、docまたはtestフォルダーなどの一般的な機能が常にいくつかあります。 しかし、大きなプロジェクトにはa libとvendorフォルダーの両方があることに気づきましたが、名前は「libraries外部からのサードパーティ」を含めることを示唆しているため、常に同じだと思っていましたvendors。ただし、同じプロジェクトで両方を見ることは、違いがあることを意味します。 これは実際には何らかの形で一般的な慣行であるにもかかわらず、GoogleやFilesystem Hierarchy Standardなどのソースに関する情報を見つけることができませんでした。 Symfonyのより詳細な例を次に示します。プロジェクトを作成すると、プロジェクトlibのルートにフォルダーが作成されます。このフォルダーには、次の構造があります。 lib +--filter +--form +--… +--vendor +--simpletest +--symfony ここでは、symfonyフォルダーにはすべてのSymfonyのコアが含まれています。

103 directory-structure 

クラスを独自のアセンブリ/ DLLに含めるタイミングを決定するためのガイドラインはありますか？私はしばしば二つの考え方を目にします： 1）クラスのすべての「グループ化」は、リポジトリ、サービス、DTO、インフラストラクチャなどの独自のDLLに属します。 2）すべてが単一のDLLにある必要がありますが、名前空間/フォルダーを介して分離する必要があります。たとえば、Core.Repositories、Core.Services、Core.DTOなどの追加の名前空間を持つ「Core」DLLが必要です。 仕事では、すべてを「ビジネス」と呼ばれる単一のアセンブリにまとめます。いくつかのフォルダーがありますが、本当の分離はありません。ビジネスオブジェクト（ロジックを含む、その一部はクラスであってはならない）は、「BusinessObjects」フォルダーに注意せずにまとめられます。複数のクラスで使用されるものは、「コア」フォルダーにあります。ユーティリティは「ユーティリティ」フォルダにあり、データアクセスインフラストラクチャは「データ」フォルダです。 私が取り組んでいる新しいモジュールの場合、個別のデータアクセスレイヤーが必要です（基本的なリポジトリ実装を考えてください）が、他の160（！）そこのクラス。同時に、誰もが単一のライブラリにクラスを詰め込むことに慣れているため、新しいクラスライブラリの作成について心配しています。ただし、フォルダ/ネームスペースは機能します。

22 c#  architecture  directory-structure 

閉まっている。この質問はトピックから外れています。現在、回答を受け付けていません。 この質問を改善してみませんか？ 質問を更新して、ソフトウェアエンジニアリングスタック交換のトピックになるようにします。 昨年休業。 私はAzureにかなり慣れていませんが、Visual Studioが（特に）次のフォルダーを自動作成することに気付きました ... /<nameOfAzureProject>/bin /<nameOfAzureProject>/obj /<nameOfAzureProject>/csx <== ... 現在、binおよびobjフォルダーはかなり標準的です。しかし、csxフォルダーの目的は明確ではありません。何か案は？

10 visual-studio  azure  directory-structure 

私の（主にC ++）開発では、長い間、ソース外ビルドの使用に固執してきました。つまり、私のソースは通常/project/srcディレクトリにあり、ビルド/project/build/bin/releaseは/project/build/bin/debugディレクトリにあります。これを行ったのは、中間ファイルからソースディレクトリをクリーンに保ち、すべてのバイナリを1か所にまとめ、パッケージ化がより簡単になり、クリーニングがより簡単になり、バージョン管理がより簡単になるからです。（私は何かを見逃しましたか？） 現在、ソース内ビルドを使用する（大きな）プロジェクトを継承しています。このタイプの構造の動機は何ですか？その利点は何ですか？（私は、エンジニアリングレベルの理由と個人的な好みのタイプの理由に最も懸念しています。） Lakosの "Large-Scale C ++ Software Design"がそれを考慮に入れてくれることを期待していましたが、そうした場合は見逃しました。

9 builds  directory-structure  large-scale-project  cmake 

状況は次のとおりです。 Node.js開発環境でP1とP2の2つのプロジェクトを開発しています。 P1では、2つの単純なモジュール、mod1とmod2の開発が必要でしたP1/lib。これらはに保存されています。このモジュールの解決はそれぞれ、外部の依存関係をで見つけます P1/node_modules。P1に必要な依存関係は、npmを介してこのフォルダーにインストールされています。 他のプロジェクトP2でmod1を再利用したい画像ですが、ここで私の疑問が浮かび上がりました。私はできた... mod1をにコピーするだけP2/libです。レプリケーションなので、このオプションは考慮していません。 P2から、P1からmod1を参照しますrequire($PROJECTS_DIR + '/P1/lib/mod1')。この方法では、P2はP1に依存します。 mod1を上位レベルのディレクトリに配置するか、NODE_PATHを使用して、P1とP2がdointだけで解決できるようにしrequire('mod1')ます。ただし、展開するときは、少し汚いように見えるこの上位レベルのディレクトリも展開する必要があります。 mod1をnpmモジュールとして扱い、どのプロジェクトや環境にも簡単にインストールできるようにしたいのですが、この特定のケースでは、モジュールをnpmに公開できないので、プロジェクト固有のものです。プライベートnpmリポジトリを作成してmod1を中に入れることができます。これの要点は、本番環境からもアクセスできるように設定することです。その価値はありますか？ それをすべてまとめてnode_modulesどうですか？（外部の依存関係と自分のライブラリ）。`require（ 'module'）のようにモジュールが必要なだけなので、それは素晴らしいことです。しかし、それもかなり汚いようです。 npm link展開時にどのように機能するかわかりません。シンボリックリンクを作成します。GitまたはSVNを介してコードをコミットする場合は、このリンクはたどられません。npm install本番環境で実行すると、リンクされたモジュールもインストールされますか？ 上記のどれも私を完全に満足させません。これらの1つが適切かどうか、または他の提案があるかどうかはわかりませんが、他のプロジェクトで簡単に再利用できるように、独自のプライベートライブラリを構築するための好ましい方法はありますか？

8 javascript  node.js  modules  directory-structure