問題タブ [project-structure]

バージョン管理でプロジェクトを構成するには、少なくとも 10 の異なる方法があることを知っています。使用されているいくつかの方法と、どの方法があなたに適しているか興味があります。私はSVN、TFS、そして現在/残念ながらVSSを扱ってきました。バージョン管理の実装が非常に貧弱で、問題はありませんが、素晴らしいとは言えませんでした。

ボールを転がすために、ここに私が見たもののレビューがあります.

この例は SVN ベースですが、ほとんどの VCS に適用されます (分散バージョン管理にはあまり適用されません)。

1. サイト /division/web/projectName/vb/src/[trunk|branches|tags] の一部である個々のプロジェクトを分岐します

2. サイト全体を分岐します。私が見た場合、コア コンポーネントを除くサイト全体が分岐されました。/部門/[幹|枝|タグ]/web/プロジェクト名/vb/src/

3. メインラインをデフォルトで使用し、大きな変更が必要な場合にのみ分岐します。

私は、ファイルごとに 1 つの public クラスを持つことができる Java モデルに慣れています。Python にはこの制限がありません。クラスを編成するためのベスト プラクティスは何だろうと思っています。

私が始めているプロジェクトには数十のコントローラーがあるので、それらを論理ディレクトリと、「Controllers / Admin /」、「Controllers / Warehouse /Supplies/」などのそれぞれの名前空間に構造化すると便利です。

ASP.NET MVCは、ネストされたコントローラーディレクトリと名前空間をサポートしていますか？これらのコントローラーへのルートを管理するにはどうすればよいですか？

Pythonで重要なエンドユーザーデスクトップ（Webではない）アプリケーションを開発したいとします。プロジェクトのフォルダ階層を構造化するための最良の方法は何ですか？

望ましい機能は、メンテナンスのしやすさ、IDEの使いやすさ、ソース管理の分岐/マージへの適合性、およびインストールパッケージの簡単な生成です。

特に：

1. ソースはどこに置きますか？
2. アプリケーション起動スクリプトはどこに置きますか？
3. IDEプロジェクトの要点はどこにありますか？
4. ユニット/受け入れテストはどこに置きますか？
5. 設定ファイルなどのPython以外のデータはどこに置きますか？
6. pyd / soバイナリ拡張モジュール用のC++などのPython以外のソースをどこに配置しますか？

私はディレクトリ構造を実験しており、現在以下のものを使用しています:

Web は Web アプリケーションを格納し、デスクトップはデスクトップ アプリケーションを格納します。dev ディレクトリはバージョン管理されており、他のディレクトリ (prod、qe、uat) にはそれぞれの最新リリースが保存されています。プロジェクト ディレクトリには、コードに関連しないプロジェクト アイテムが格納されます。

ソフトウェア開発のディレクトリ構造はどのようなものですか? また、その構造を推奨する理由はありますか?

画面 DTO を使用してService LayerとPresentation Layerの間のデータをカプセル化するプロジェクトがあります。この場合、プレゼンテーション層は ASP.Net です。

DTO について知っている唯一のクラスは、サービス層クラスと、これらのサービスを呼び出して DTO を表示するページ/コントロールです。

DTO はほとんどの場合ページ/コントロール固有であるため、プレゼンテーション層に属していると思いますが、DTO を使用するには、サービス層がプレゼンテーション層を参照する必要があることを意味します。

私は、サービス層がより豊富なオブジェクトを返す必要があると考えています (ただし、ドメイン エンティティではありませんか?)。次に、プレゼンテーション層がこれらのオブジェクトを取得し、ページ/コントロールの懸念ごとに非常に具体的な DTO にマップできます。

ここにインターフェイス宣言と DTO があるので、私が話していることがわかります。

編集

ドメイン モデルが関与しないユース ケースを説明する別のコード サンプルを次に示します。多分これは物事を少し明確にするでしょう。DTO の意味を過負荷にしていると思います。私は、ネットワーク上でオブジェクトを転送する機能のための DTO について話しているのではありません。サービス層への通信間の契約を形式化するために DTO を作成しています。

たとえば、私の認証で突然 IP アドレス パラメータが必要になったとします。コントラクト インターフェイスを変更せずに、そのプロパティを DTO に追加できるようになりました。

プレゼンテーション レイヤーにエンティティを渡したくありません。自分のコード ビハインドに移動機能を持たせたくないBlogPost.AddComment(new Comment())

サードパーティ製コンポーネントのインストールは、大きなコンポーネントがある場合は特に時間がかかりますが、複数のコンピューターで環境をセットアップする場合はさらに時間がかかります。

そして、それらをバージョン管理 (Subversion) に追加することを考えているので、必要なすべてのコンポーネントを含むプロジェクトをいつでも簡単にチェックアウトできます。

では、それをどのように管理し、VCS 内で管理するためのベスト プラクティスは何ですか?

また、これらのサードパーティのいくつかは、ソースなしで Delphi ライブラリとして提供されていることも考慮してください。（BPL）。

この質問はこの質問に似ていますが、その質問で説明されていない問題について質問しているため、重複していません。

Delphi 7 に、次のディレクトリ構造を持つクライアント サーバー プロジェクトがあります。

MyClientApp フォルダーと MyServerApp フォルダーにそれぞれ 1 つずつ、2 つの実際の Delphi プロジェクト (.dpr) があります。

lib フォルダーには、クライアント アプリとサーバー アプリに共通のコードを持つ .pas ユニットがあります。私が疑問に思っているのは、これらの .pas ファイルをクライアント プロジェクトとサーバー プロジェクトに含める必要があるかどうかということです。または、これらのユニットを含む lib フォルダーにパッケージを作成する必要がありますか? または、.pas ファイルを lib フォルダーに置いたままにして、アプリ/パッケージに追加しないようにする必要がありますか?

各アプローチの長所と短所は何ですか? どの方法が「最良」ですか？lib フォルダーのユニットを複数のプロジェクトに含めることに問題はありますか?

現在、lib フォルダー内のユニットはアプリ/パッケージの一部ではありません。これの欠点の 1 つは、たとえば、Delphi でクライアント アプリを開いているときに、プロジェクト内のすべてのファイルで何かを検索したい場合、lib フォルダー内のユニットも検索されないことです。これらのユニットを開いて開いているすべてのファイルで検索を行うか、grep検索を使用することでこれを回避します（ただし、より良い解決策が望ましいです）。

また、lib フォルダー内のファイルに変更を加えたときに、別のパッケージを開いて再コンパイルする必要がないソリューションを大いに好むでしょう (これはプロジェクト グループを使用する必要がある場所ですか?)。

ruby (非レール/merb/etc) プロジェクトの理想的なプロジェクト構造の概要/明確化を求めています。多分続くと思います

何か間違っていますか？どの部分を見逃しましたか?

簡単に言えば、maven を使用している場合、maven レイアウトをゴールド スタンダードとして扱うべきですか、それともツール (WASD、myEclipse、RAD など) に合わせてレイアウトを変換する必要がありますか?

Maven は構成可能であり、Super POM のデフォルトをオーバーライドできることに気付いたので、社内の特定のツールをサポートするためにレイアウトを変更する必要があるかどうか、またはそれらのツールに Maven レイアウトを認識させるようにする必要があるかどうかを判断しようとしています。考慮すべきことの 1 つは、継続的なビルド ツールの最終的な統合と、使用中のさまざまな IDE です。MyEclipse は現在使用されていますが、6 か月後にライセンスを更新しないという噂があります。

この種のことに関して私が最初に尋ねた質問は、少し具体的すぎて一方的なものでした。