プロジェクトをどのように整理しますか？[閉まっている]

プロジェクトを整理する特定のスタイルはありますか？

たとえば、現在ボリビアのいくつかの学校でプロジェクトを作成していますが、これが私がそれを整理した方法です。

TutoMentor (Solution)
TutoMentor.UI   (Winforms project)
TutoMentor.Data (Class library project)

プロジェクトをどのように整理しますか？あなたが組織し、誇りに思っているものの例はありますか？ソリューションペインのスクリーンショットを共有できますか？

私のアプリケーションのUI領域では、さまざまなフォームとそれらが属する場所を整理するための適切なスキーマを決定するのに苦労しています。

編集：

.UIプロジェクトでさまざまなフォームを整理するのはどうですか？どこで/どのように異なるフォームをグループ化する必要がありますか？それらをすべてプロジェクトのルートレベルに配置するのは悪い考えです。

プロジェクトを設計し、アーキテクチャをレイアウトするとき、2つの方向から始めます。最初に、設計中のプロジェクトを見て、解決する必要があるビジネス上の問題を判断します。私はそれを使用する人々を見て、粗いUIデザインから始めます。この時点で、データを無視し、ユーザーが何を求めているのか、誰がそれを使用するのかを検討しています。

彼らが求めているものの基本的な理解が得られたら、コアデータが何を操作するのかを判断し、そのデータの基本的なデータベースレイアウトを開始します。次に、データを取り巻くビジネスルールを定義するために質問を始めます。

両端から独立して開始することで、2つの端を結合する方法でプロジェクトをレイアウトできます。私は常に、それらを一緒に結合する前に、可能な限り長い間別々にデザインを維持しようとしますが、私が前進するとき、それぞれの要件に留意してください。

問題の両端をしっかりと理解したら、問題を解決するために作成されるプロジェクトの構造のレイアウトを開始します。

プロジェクトソリューションの基本レイアウトが作成されたら、プロジェクトの機能を確認し、実行する作業の種類に応じて使用される名前空間の基本セットを設定します。これには、アカウント、ショッピングカート、アンケートなどがあります。

これは、私がいつも始めている基本的なソリューションレイアウトです。プロジェクトの定義が良くなると、各プロジェクトの特定のニーズを満たすようにプロジェクトを改良します。一部の領域は他の領域と統合される場合があり、必要に応じていくつかの特別な領域を追加する場合があります。

ソリューション名

.ProjectNameDocuments
    For large projects there are certain documents that need to be kept with
    it. For this I actually create a separate project or folder within the 
    solution to hold them.
.ProjectNameUnitTest
    Unit testing always depends on the project - sometimes it is just really 
    basic to catch edge cases and sometimes it is set up for full code 
    coverage.  I have recently added graphical unit testing to the arsenal.
.ProjectNameInstaller
    Some projects have specific installation requirements that need to be 
    handled at a project level.
.ProjectNameClassLibrary
    If there is a need for web services, APIs, DLLs or such.
.ProjectNameScripts (**Added 2/29/2012**)
    I am adding this because I just found a need for one in my current project.  
    This project holds the following types of scripts: SQL (Tables, procs, 
    views), SQL Data update scripts, VBScripts, etc.
.ProjectName
    .DataRepository 
        Contains base data classes and database communication.  Sometimes 
        also hold a directory that contains any SQL procs or other specific 
        code.  
    .DataClasses
        Contains the base classes, structs, and enums that are used in the 
        project.  These may be related to but not necessarily be connected
        to the ones in the data repository.
    .Services 
        Performs all CRUD actions with the Data, done in a way that the 
        repository can be changed out with no need to rewrite any higher 
        level code.
    .Business
        Performs any data calculations or business level data validation,
        does most interaction with the Service layer.
    .Helpers
        I always create a code module that contains helper classes.  These 
        may be extensions on system items, standard validation tools, 
        regular expressions or custom-built items.  
    .UserInterface
        The user interface is built to display and manipulate the data.  
        UI Forms always get organized by functional unit namespace with 
        additional folders for shared forms and custom controls.

プロジェクトをレイヤーに分割するのが好きです

そうすれば、周期的な依存関係を管理しやすくなります。たとえば、誤ってViewプロジェクト（レイヤー）をインポートするプロジェクトがないことを保証できます。また、レイヤーをサブレイヤーに分割する傾向があります。したがって、私のすべてのソリューションには、次のようなプロジェクトのリストがあります。

• Product.Core
• 製品モデル
• Product.Presenter
• Product.Persistence
• Product.UI
• Product.Validation
• Product.Report
• Product.Web

それらは、私のアプリケーションの大きな「ビルディングブロック」です。その後、各プロジェクト内で名前空間をより論理的に整理しますが、それは大きく異なります。多くのフォームを作成するときのUIの場合、私は空間区分で考えてから、各「スペース」の名前空間を作成しようとします。ユーザー設定のユーザーコントロールとフォームがたくさんあるとしましょう。それらにはUserPreferencesという名前空間があります。

プロジェクトの整理

あなたが言うように、私は通常、プロジェクトを名前空間で分割しようとします。アプリケーションまたはコンポーネントの各層は、独自のプロジェクトです。ソリューションをプロジェクトに分割する方法を決定する方法に関しては、それらのプロジェクトの再利用性と依存関係に焦点を当てています。私のチームの他のメンバーがプロジェクトをどのように使用するかを考えます。将来作成する他のプロジェクトがシステムの一部のコンポーネントを使用することで利益を得る場合があります。

たとえば、フレームワーク（メール、ロギングなど）のセット全体を備えたこのプロジェクトだけで十分な場合があります。

MyCompany.Frameworks

また、フレームワークを分割して、個別にインポートできるようにすることもできます。

MyCompany.Frameworks.Networking
MyCompany.Frameworks.Logging
MyCompany.Frameworks.SomeLOBFramework

フォームの整理

UIプロジェクトの下でフォームを整理することは、プロジェクトが拡大するにつれて実際に変化します。

• 小 - 非常に小さなプロジェクトには、単純なFormsフォルダーで十分です。名前空間と同じように構造をオーバーエンジニアリングし、必要以上に複雑なものにすることができます。

• 中から大 -ここでは、通常、フォームを機能領域に分割し始めます。ユーザーを管理するための3つのフォームとサッカーゲームとスコアを追跡する一部を含むアプリの一部がある場合、フォーム>ユーザーエリアとフォーム>ゲームエリアなどがあります。それは、プロジェクトの残りの部分、細かく分割するためのフォームの数に依存します。

結局のところ、名前空間とフォルダーは、物事をより迅速に整理して見つけるのに役立つためにそこにあります。

本当に、それはあなたのチーム、あなたのプロジェクト、そしてあなたにとってより簡単なものに依存します。一般に、システムのレイヤー/コンポーネントごとに個別のプロジェクトを作成することをお勧めしますが、常に例外があります。

システムアーキテクチャのガイダンスについては、Microsoftのパターンと実践のサイトを参照してください。

.NETでコードを書くとき、関連する機能のクラスターを持つ傾向があることが明らかです。それぞれに同じサブセットが含まれる場合があります。VSプロジェクトごとに1つ、メイングループを物理的に分割するのが好きです。次に、アセンブリを使用して論理的にさらに分割します。このパターンに従って、現在のプロジェクトの1つは次のようになります。

• Wadmt（ソリューション）
  • Wadmt.Common
  • Wadmt.Data
    • Wadmt.Data.MySql
    • Wadmt.Data.SqlServer
    • Wadmt.Data.Oracle
  • Wadmt.Domain
  • Wadmt.Services
  • Wadmt.Tests
    • Wadmt.Tests.Common
    • Wadmt.Tests.Domain
    • Wadmt.Tests.Services
    • Wadmt.Tests.Integration
  • Wadmt.Web

うまくいけば、それはあなたにとって有用です。分離のレベルを理解するのに時間がかかりました。

ソリューションを整理する計画を立てるのは良いことであり、それを行う方法はいくつかあります。複数のプロジェクトで共有されるいくつかの機能があり、ユーザーに一貫性を提供します。プロジェクトの組織は、私たちが何をしているかに依存します。その中核には次のものがあります。

Company (solution)
  Company.Common (shared library)
  Company.Project (Main application UI)
  Company.Project.UnitTests (Unit tests for all project modules)
  Company.Project.IntegrationTests (integration tests for all project modules)
  Company.Project.AutomationTests (tests that invoke the UI)

そこから、それは本当にセットアップに依存します。クライアントアプリケーションとWebフロントエンド（教室やその他の研究で使用結果を収集するのに便利）の両方がある場合、共通のコード（つまり、シリアル化されるデータオブジェクト）を持つプロジェクトが必要です。

  Company.Project.Model (ORM and business logic layer)
  Company.Project.Webapp (Web frontend/web service layer)
  Company.Project.WebClient (client code for web services)

必要に応じて、他のサブプロジェクトを追加できます。私が言ったように、それは本当にプロジェクトに依存します。一部のプロジェクトは本当にシンプルで、コア要素のみが必要です。私たちは任意のプロジェクトの分離と戦おうとしているので、レイヤーで分割することは本当に意味があります。レイヤーは、プロジェクト、ソリューション間で共有する必要があるもの、またはプラグイン/拡張機能にする必要があるものによって定義されます。

非常に多くの人がここでDRYを考慮しないのは興味深いことです。私の人生で、開発者がそのために構築できないディレクトリ構造を作成したことが何度かありました。ソリューションおよびプロジェクトディレクトリからプロジェクト名を除外してください！

だからここに私の方法があります：

{drive}:\{customer}\{apps|libs|tools}\{project}
  - cer
  - res
  - src
   - Common
   - Data
   - UI
   - Logic
   - Logic._Tests  

アプリケーションを設計しているとき、常にいくつかの依存関係を持つモジュールとしてそれを見る。デザインを念頭に置いてから、ボトムアップ戦略を使用してそれを開発します。私は、各モジュールを開発し、その後、私は彼らが一緒に仕事を取得します。

まあ、それらのモジュールは私のソリューション（通常はクラスライブラリ）の下のプロジェクトです。各モジュールには、異なる名前空間と独自のデザイン（クラスなどを含む）があります。

それらの一つのモジュールがあるGUI（グラフィカルユーザインタフェース）。

また、常にリビジョン管理ツールを使用して、各プロジェクトの変更を追跡しています。Gitをお勧めします。オープンソースで、配布されており、無料で使用できます。

新しいプロジェクトを開始するたびに、それが何をすべきかについての広範な仕様を取得します。この入力があると、コンテキストを提供してくれます。そのため、プロジェクトの目標を達成するための最良の（または最も適切な）方法を考えます。この時点で、どの設計パターンが意図したソリューションを提供できるかを考え始めます。ここで、プロジェクトに採用するデザインパターンを考慮して、プロジェクトの編成を開始します。

いくつかの例：

1. プロジェクトが入力データ画面の構築のみに関係する場合。ほとんどの場合、MVCパターンを使用します。
2. 複数のプラットフォームを最もサポートするヘビーデューティUIとしてプロジェクトを使用する場合、MVVM設計パターンが役立ちます。

これらはそれぞれ、特定の方法でプロジェクトを編成することを強制することに留意してください。

ここにあなたのためのいくつかの読書があります：

.NETのデザインパターン。

デザインパターン。

オブジェクト指向設計。

お役に立てれば。