12

私は、.NET Entity Frameworkプロジェクトを設計して、優れた階層型アプローチを実現するための最善の方法を決定しようとしています。これまで、プレイヤーが惑星を所有して操作するブラウズベースのゲームで試してみました。これが私がそれを持っている方法です：

Webサイト

これにはすべてのフロントエンドが含まれます。

C＃プロジェクト-MLS.Game.Data

これには、すべてのデータマッピングを含むEDMXファイルが含まれています。ここでは他にあまりありません。

C＃プロジェクト-MLS.Game.Business

これには、PlanetManager.csなどの「マネージャー」と呼ばれるさまざまなクラスが含まれています。惑星マネージャーには、MLS.Game.Dataから生成されたコードオブジェクトを返すgetPlanet（int planetID）など、惑星との対話に使用されるさまざまな静的メソッドがあります。

ウェブサイトから、私はこのようなことをします：

var planet = PlanetManager.getPlanet(1);

MLS.Game.Data（EDMXから生成）からPlanetオブジェクトを返します。それは機能しますが、フロントエンドがMLS.Game.Dataを参照する必要があることを意味するため、ある程度気になります。しかし、GUIはビジネスプロジェクトを参照するだけでよいといつも感じていました。

さらに、私のマネージャークラスは非常に重くなる傾向があることがわかりました。結局、数十の静的メソッドが含まれることになります。

だから...私の質問は-他のみんなはどのようにASPEFプロジェクトをレイアウトするのですか？

編集

しかし、もう少し後、私を悩ませている追加のアイテムがあります。たとえば、Planetオブジェクトがあり、これもウィザードから生成されたコードであるとします。私の惑星が特殊なプロパティを持っている必要があるときが来たらどうしますか？たとえば、惑星オブジェクトの他のプロパティに基づいたある種の計算である「人口」と言います。Planetから継承する新しいクラスを作成し、代わりにそれを返しますか？（うーん、それらのクラスはEFによって封印されているのだろうか？）

ありがとう

4

7 に答える 7

3

あなたは物事を改善するために以下を試すことができます：

  • EFを使用してデータレイヤーのDTOをフェッチし、これらのDTOを使用してビジネスレイヤーのよりリッチなビジネスオブジェクトにデータを入力します。その場合、UIはビジネスレイヤーを参照するだけで済みます。
  • 豊富なビジネスオブジェクトを作成したら、マネージャークラスのロジックの一部を内部化して、ビジネスレイヤーを効果的にクリーンアップできます。

個人的には、マネージャーモデルよりもリッチなモデルの方が好きです。なぜなら、あなたが言うように、静的メソッドが大量に発生し、必然的に他の静的メソッド内で連鎖してしまうからです。私はこれがあまりにも厄介であり、さらに重要なことに、特定の時点でのオブジェクトの一貫性を理解して保証するのが難しいと感じています。

クラス自体にロジックをカプセル化すると、外部の呼び出し元の性質に関係なく、オブジェクトの状態をより確実に把握できます。

ちなみに良い質問です。

于 2009-02-14T13:29:52.337 に答える
2

私見、あなたの現在のレイアウトは大丈夫です。UIが「データ」レイヤーを呼び出すときにそれを参照するのは完全に正常です。用語のせいで気になるのではないかと思います。あなたが説明した「データ」は、「ビジネスオブジェクト」（BOL）レイヤーと呼ばれることがよくあります。一般的なレイアウトは、「マネージャ」層とデータアクセス層（DAL）であるビジネスロジック層（BLL）を持つことです。シナリオでは、LINQ to Entites（これを使用すると想定）がDALです。通常の参照パターンは次のようになります。-

UIはBLLとBOLを参照します。BLLは、BOLとDAL（LINQ to Entites）を参照します。

詳細については、この一連の記事をご覧ください。

于 2009-02-14T13:33:36.900 に答える
1

「編集」セクションの2番目の質問について：

私が間違っていなければ、EF によって生成されたクラスはシールされておらず、PARTIALクラスであるため、生成されたファイル自体に触れることなく簡単に拡張できます。

生成されるクラスは次のようになります。

public partial class Planet : global::System.Data.Objects.DataClasses.EntityObject
{
 ...
}

そのため、独自の「PlanetAddons.cs」(または任意の名前) を簡単に作成して、このクラスを拡張できます。

public partial class Planet 
{
 property int Population {get; set;} 
 ...
}

かなりきれいですね。人工的なオブジェクト階層を派生させて作成する必要はありません....

マルク

于 2009-02-26T17:18:15.503 に答える
0

データレイヤー内のエンティティの「ダムオブジェクト」表現（つまり、プロパティのみ）であるDTOをビジネスレイヤーに追加します。次に、「Manager」クラスは次のようにそれらを返すことができます。

class PlanetManager
{
    public static PlanetDTO GetPlanet(int id) { // ... }
}

UIはPOCOを介してのみBLLレイヤーを処理できます。Manager（私が「Mapper」クラスと呼ぶもの）は、オブジェクトとデータレイヤー間のすべての変換を処理します。また、クラスを拡張する必要がある場合は、DTOオブジェクトに「仮想」プロパティを設定し、マネージャーにそれをそのコンポーネントに変換して戻すことができます。

于 2009-02-16T16:01:54.270 に答える
0

私は専門家ではありませんが、それは私にはかなりいいですね。EFプロジェクトをビジネスプロジェクトとマージすることを除けば、これは私のソリューションにあるものと似ています。私のソリューションはそれほど大きくはなく、私のオブジェクトは多くのインテリジェンスを必要としないので、私にとっては問題ありません。私も静的ヘルパークラスごとにたくさんの異なるメソッドを持っています。

プレゼンテーション層にデータアクセス層を認識させたくない場合は、いくつかの中間クラスを作成する必要がありますが、これはおそらく多くの作業になります。では、現在の設定の問題は何ですか？

于 2009-02-14T13:10:28.203 に答える