0

私は、BusinessObjects (ロジックを含まず、プロパティのみを含む) を使用する C# Winforms アプリと、それらのエンティティを操作するクラス (「ヘルパー」) を含む BusinessLayer のサポートを担当しています。

質問: BusinessObject をヘルパー コンストラクターに渡してから、コンストラクター内で、ヘルパーのパブリックにアクセス可能なエンティティ変数をインスタンス化する必要がありますか、それとも、エンティティに基づいて動作するメソッドにエンティティを渡すだけですか?

シナリオ 1: コンストラクターへ

Car myCar = new Car();
CarHelper ch = new CarHelper(myCar);
ch.Wash(suds);
ch.Upgrade(upgradeKit);
ch.Save();

シナリオ 2: Entity に作用するメソッドへ

Car myCar = new Car();
CarHelper ch = new CarHelper();
ch.Wash(myCar, suds);
ch.Upgrade(myCar, upgradeKit);
ch.Save(myCar);

シナリオ 1 で私が抱えている 2 つの大きな問題: A) 次の開発者は、CarHelper クラスを掘り下げて、それを必要とするメソッド内で参照する public Car アクセサー プロパティがあることを認識する必要があります。これにより、各メソッドがその役割を実行する前に「null」の Car プロパティをチェックする必要があるという点で、ヘルパー クラスがさらに難読化されます... B) 操作の間に他のコードが多数存在する場合、どの ch.Wash( ）は実際にやっています...それはCarオブジェクトにも作用しますか...？

みんなはどう思う？？？

4

3 に答える 3

0

それは非常に真実です...BusinessObjectのロジックをラップして自己認識させるのも私の意見では最善です...しかし、私はそのオプションを考慮しませんでした。理由は次のとおりです。

「アプリケーション」では、BusinessObjectsはDAOによって参照される名前空間（.... ApplicationServices）にあるため、実際にはDAOメソッドを呼び出すことができません（循環依存が発生するため）。したがって、実装できません。の機能

myCar.Wash(suds)
{
    this.CleanlinessRating = suds.CleaningAbilityRating;    
    // persist the level of Cleanliness to the DB
    CarDAO.Save(this);
}

アプリケーション全体の背後にある前提は、BusinessObjectsがロジックをまったく実装していないことであるように思われます...それらは単なる情報のコンテナであり、動作はありません。

次に、エンティティに作用するBusinessLayerクラスがあります...

次に、DBへのエンティティの変更を永続化するDataLayerクラスがあります。

したがって、明らかに、エンティティを自己認識させ、独自の動作を実装することは、（このアプリケーションでは）大きな「ノーノー」です...これがここでの本当の問題であると確信しています。

しかし、私がそれを変えることができないと仮定して、あなたはどうしますか？

  1. エンティティをそれに作用するメソッドに渡しますか？また
  2. エンティティをHelperクラスのコンストラクターにラップしますか？
于 2011-05-27T01:37:38.973 に答える
0

ロジックを BusinessObject に移動できない理由はありますか

Car myCar = new Car();
myCar.Wash(suds);
myCar.Upgrade(upgradeKit);
myCar.Save();

ヘルパー クラスを完全に廃止します。よりセマンティックに読むことができ、null をチェックする必要はありません。

維持するクラスも半分に

于 2011-05-27T01:32:49.253 に答える
0

CarHelper クラスを Car 拡張するのはどうですか

CarHelper helper = new Car();
helper.Wash(suds);
helper.Upgrade(upgradeKit);
helper.Save();

両方の長所

于 2011-05-27T01:44:44.433 に答える