1

私のチームは、最初の Silverlight 4 アプリケーションの作成に取り組んでいます。まず、実際のプロジェクトについて少し詳しく説明します。Out-of-Browser を実行するように設計されたのは Silverlight 4 であり、Dataobjects の独自の実装でデータ サービスに WFC を使用します。(エンティティ フレームワーク、LINQ-to-SQL などはありません)。11 を超える個別のプロジェクトを含むソリューション構造を推奨しているコンサルタントが数人います。私たちにはその理由がないように思われますが、次のようなものが必要な理由について正当化できる人はいますか?

  • Project.Client - アセット、スタイル、ビュー
  • Project.Common - コンバーター、ヘルパー
  • Project.Data - 不明な目的 (クライアント プロジェクト)
  • Project.Infrastructure - コマンド、定数、インターフェイス、ロギング
  • Project.MajorFunctionA - 「アプリケーションの主要機能 A のビジネス ロジック」
  • Project.MajorFunctionB - 「アプリケーションの主要機能 A のビジネス ロジック」
  • Project.MajorFunctionC - 「アプリケーションの主要機能 A のビジネス ロジック」
  • Project.Models - WCF サービスへの抽象化されたアクセス
  • Project.UIControls - UI のカスタム コントロール
  • Project.UnitTests - "潜在的にすべての単体テスト"
  • Project.ViewModels - UI のビュー モデル
  • Project.Web - Silverlight アプリのホスト プロジェクト - コードなし
  • Project.Web.Infrastructure - データ オブジェクトと WCF サービス

さて、私たちの主な混乱は、アプリケーションの小さなコンポーネントである「Project.MajorFunctionA」のようなものと同様に、それらを分離するために名前空間だけを除外しない理由と、なぜ独自のプロジェクトを持たなければならないのかということです。(その特定の関数のビューとビューモデルは、そのプロジェクトではなく、他のクライアント/ビューモデル プロジェクトに存在することに注意してください。

これには理由が見当たらないので、何らかの検証を求めているだけです。

4

1 に答える 1

3

同意: プロジェクトではなく、論理的な編成に名前空間を使用します。アプローチの 1 つは、プロジェクトを展開の単位と考えることです。Project.Client は常に Project.ViewModels と共にデプロイされますか? プロジェクト.モデル? 一方が他方を参照していますか？同じプロジェクトに含めて、整理のために名前空間を使用するだけです。

Silverlight クラス ライブラリ/アプリケーションを個々のプロジェクトに分割する理由はいくつかあります。

  • 再利用。他のアプリケーションで使用される API を開発したいと考えています。Project.Infrastructure は、このカテゴリに分類される場合があります。
  • モジュール性。MajorFunctionA は、エンド ユーザーによって 20% の時間のみ使用されます。特定の認証済みユーザーのみがアクセスできる可能性があります。おそらく、誰もアクセスしない特定のページに移動したときのみのアクセスです。別の Silverlight アプリにビルドし、MEF や PRISM などのフレームワークを使用して、必要に応じて .xaps のみをダウンロードすることを選択できます。
  • 開発者ワークフロー。ある都市/オフィスの 1 つのチームが Project.Client に取り組んでおり、別の都市/オフィスの別のチームが Project.Models に取り組んでいます。生活を楽にするために、別々のプロジェクトに組み込むことは理にかなっているかもしれません。

アセンブリに関するもう 1 つの注意点は、アセンブリ間で循環参照を行うことができないことです。つまり、ClassA と ClassB が同じアセンブリ内にある場合、ClassA は ClassB を参照でき、ClassB は ClassA を参照できます。しかし、それらが別々のアセンブリにある場合、それらはできません。クラスに多くの循環参照がある場合、それはおそらく良いことではありませんが、回避するのが難しい場合があり、それらが別のアセンブリにある場合、オプションははるかに制限されます. しかし反対に、アセンブリの数を増やすと、循環参照の可能性が制限され、設計の品質が向上する可能性があります。他に知っておくべきことがあります。

このロジックに従うと、1 つの代替案として、Project.Client、Project.Data、Project.Model、Project.UIControls、および Project.ViewModels を 1 つのプロジェクトにグループ化し、Project.Common および Project.Infrastructure を別のプロジェクトにグループ化します。MajorFunctions は、別々のままにすることも、Project.Client にグループ化することもできます。最終的には次のようになります。

  • Project.Client - アプリケーション固有のインターフェイス、ビュー モデル、およびモデル。
  • Project.Infrastructure - 共通の再利用可能なヘルパー、コンバーター、およびインターフェイス。
  • Project.UnitTests
  • プロジェクト.Web
  • プロジェクト.Web.インフラストラクチャ

また。これには本当に正しい答えはありません。コミュニティ Wiki としてタグ付けしています。

于 2010-09-30T00:05:10.643 に答える