質問

次のプロジェクトを含むVSソリューションがあります。

-GUI
-DataAccess
-BusinessLogic
-BusinessObjects

しかし、メインモデルクラスはどこにあるべきですか?これは通常、データアクセスレイヤーと仮想グリッドを使用してモデル内のデータを表示するGUIからの結果であるオブジェクトのセットのキャッシュです。質問は、MVCまたはMVPを使用した場合と同じです

思考?

役に立ちましたか?

解決

これは主観的な質問ですが、多くの場合、モデルオブジェクトがインフラストラクチャに直接依存しないことを強制するために、人々はそれらを別のプロジェクトに配置することがよくあります。他のプロジェクトがこれらのモデルオブジェクトを使用する可能性があるものも考慮する必要があります。

機能を個別の展開可能なユニット(アセンブリ)に分割する別のオプションは、チームがより独立して機能できるようにすることです。展開の頻度とチームの自律性に基づいてプロジェクトを分けます。

最後に、モデルオブジェクトがリモートで呼び出され(.NETリモート処理など)、Webサーバーとは別のアプリケーションサーバーで提供されるプロジェクトを見てきました。このアプローチは本当にお勧めしませんが、オプションです。

それらを再利用する予定がなく、同じアセンブリに配置することで、そのプロジェクトで定義されている他のものと相互依存関係を作成できる という事実を認識している場合、あなたはそれをしないほど賢く、それらをすべて同じプロジェクトに置くことができます。

とはいえ、私がこれらのプロジェクトを持っている時間の99%は次のとおりです。

  • UI
  • コア
  • 永続性
  • テスト

ただし、プロジェクトのニーズを考慮する必要があります。

他のヒント

私は持っている傾向があります

  • Justice.Project.Core — POCOドメインモデル—すなわち、ビジネスオブジェクト)
  • Justice.Project.Data —永続化スキームが存在するNHibernateマッピングなど
  • Justice.Project.Services —リポジトリ、およびビジネスオブジェクトに簡単に適合できないビジネスロジック
  • Justice.Project。(Web | UI)

モデルはビジネスオブジェクトです –またははずです

私のソリューションには3つの(非テスト)プロジェクトがあります

  1. UI-明らかな
  2. コア-すべてのドメインオブジェクトとビジネスロジック
  3. データアクセス-モデルオブジェクトを作成/保存するためのリポジトリパターン
  

iは、モデルオブジェクトが   ポコ。だから注文があると言ってみましょう   オブジェクト。私の質問はどこにありますか   のコレクションを格納するクラス   注文??

それはあなたのビジネスに依存します。ほとんどの場合、いくつかの異なる場所に注文のコレクションがあります...

顧客オブジェクトでは、各顧客が注文のコレクションを持つ必要があるため、そこに注文があります。

部署がある場合、各部署には作成した注文のコレクションが必要です。

倉庫がある場合、各倉庫には履行を担当する注文のコレクションがある場合があります。

一部のオブジェクトには親がないため、問題ありません。私のシステムには、クライアントがいます。クライアントの実際の所有者は私たち(ビジネス)ですが、「私たち」はいません。システム内のオブジェクト。クライアントのリストを取得したい場合(この場合)、リポジトリを照会します。

IRespoistory<Client> repository = new Repository<Client>();
IList<Client> clients = repository.GetAllClients();

同じことが注文にも当てはまります。

このDDDの本をご覧になることをお勧めします: http://www.amazon *

scroll top