web-dev-qa-db-ja.com

プロジェクトをどのように整理しますか？

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

たとえば、現在ボリビアのいくつかの学校向けのプロジェクトを作成していますが、次のように編成しました。

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

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

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

編集：

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

c#.netwinformscode-organization
150
Sergio

プロジェクトを設計してアーキテクチャをレイアウトするとき、私は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.
109
Amy Patterson

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

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

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

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

69
Alex

プロジェクトの整理

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

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

MyCompany.Frameworks

また、フレームワークを細かく分割して、個別にインポートできるようにしたい場合もあります。

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

フォームの整理

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

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

  • 中から大-ここでは、通常、フォームを機能領域に分割し始めます。ユーザーを管理するための3つのフォームを持つアプリの一部と、サッカーの試合とスコアを追跡する一部がある場合、フォーム>ユーザーエリアが表示されますフォーム>ゲームエリアまたはそのようなもの。それはプロジェクトの残りの部分、どれだけ細かく分割するかについて私がいくつのフォームを持っているかに本当に依存します。

1日の終わりには、名前空間とフォルダが存在するので、物事をすばやく整理して見つけることができます。

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

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

19
Ryan Hayes

.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

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

12
Grant Palin

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

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)

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

7
Berin Loritsch

多くの人がここでDRYを考慮していません。開発者がそのために構築できないディレクトリ構造を作成したことが数回ありました。プロジェクト名を保持することは、興味深いことです。ソリューションとプロジェクトのディレクトリから外します！

これが私のやり方です：

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

アプリケーションを設計しているときは、常にmodulesのように見え、それらの間にはdependenciesがあります。デザインを考えているときは、bottom-up戦略を使用して開発します。各モジュールを開発し、、次に一緒に動作させます。

まあ、それらのモジュールはprojectsで私のsolution（通常class libraries）。各モジュールには、異なる名前空間と独自の設計（クラスなどを含む）があります。

それらのモジュールの1つは[〜＃〜] gui [〜＃〜]（グラフィカルユーザーインターフェイス）。

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

2
Oscar Mederos

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

いくつかの例：

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

これにより、特定の方法でプロジェクトを編成する必要があることに注意してください。

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

。Netデザインパターン 。

デザインパターン 。

オブジェクト指向設計 。

お役に立てれば。

1
El Padrino