2009-05-03 5 views
2

オブジェクト(IsNew、IsDirty)とINotifyPropertyChangesインターフェイスの変更を追跡するためのインターフェイスの実装など、いくつかの共通の動作を行うために、EntityBaseのような基本ビジネスクラスを作成したいと考えています。基本的なビジネスクラス:それは悪いですか?

しかし、多くの人は、基本的なビジネスクラスを持ち、それからすべてのビジネスオブジェクトを派生させるのは悪い考えだと言います。通常、彼らはエンティティクラスにプレゼンテーションコードを持つことは悪いと言います。しかし、私は単なる理論だと思う。実際に悪いのは何ですか?彼らは言う:自分でそれを試してみてください。通常、これ以上の議論はありません。

あなたはどう思いますか?それは良いか悪いですか?悪い場合は、なぜですか?理論的ではなく実践的な人になろう。

答えて

1

悪いです。私たちはこれを数年間持っていました。基本クラスに入れることはできませんでした。それは、継承されたすべてのクラスに適用できるほど一般的でした。

2

多くの人々は、クラスが唯一の責任の一つの面積を持つべきであると言うSingle Responsibility Principleのアイデア、に加入します。状態の追跡、レンダリングなどを共通の基底クラスに組み込むことで、SRPに違反することは確かです。クラスが多くのタスクを処理する場合は、変更する必要があります。

+0

ここで練習に行きましょう。 ビジネスクラスにIsDirtyプロパティを追加すると何が悪いですか? – nightcoder

+0

必ずしも悪いことはありませんが、これらの変更を追跡したいので、私はあなたも反応したいと思います。解決策は、他のタイプが変更を監視して対応できるようにイベントメカニズムを追加することです。そうすれば、異なるクラスで異なる反応を実装することができます。 –

+0

外部クラスはビジネスクラスではなく変更に反応します。たとえば、IsDirty = trueの場合、EntityService.Save(entity)メソッドはスキップするのではなく保存します。このスキームでは何が悪いですか? – nightcoder

0

オブジェクト指向設計の観点からは最も洗練されたソリューションではないかもしれませんが、データバインディングを使用する場合は、基本クラスにINotifyPropertyChangedを実装することをお勧めします。このようにして、すべてのエンティティに実装する負担を最小限に抑えることができます。

チェンジトラッキングの場合、基本クラスからその責任を分けたい場合はUnit of Workパターンを見てください。ただし、変更トラッキングが実装されていることはよくあります。 ORMに頼ってはいけません。

0

ビジネスエンティティに必要な共通の機能を提供するインターフェイスを実装するインターフェイスとベースクラスのセットを持つことは必ずしも悪いことではありません。ビジネスエンティティがそれらから派生する必要がない場合基本クラス。これにより、実装の柔軟性を実現しながら、実装の利便性を提供します。例えば

、私は私が作成したちょうど約すべてのビジネス・オブジェクトに適用されますIValidatedEntityインタフェースを持っています。ビジネスオブジェクトがいくつかの検証規則を実装することが必要です。しかし、私の監査オブジェクトは内部でのみ作成され、私は無効な監査オブジェクトを作成することができないため、これらのクラスはIValidatedEntityインターフェイスを実装しないようにユニットテストを行います。

Webからの入力XsSValidatedEntityクラス(IValidatedEntityインターフェイスを実装しています)から派生した文字列データを含みますが、HTMLパーサーを介してXSSチェックを行い、HTMLをデータベースに挿入しないようにします。私のクラスの大半はうまくいきますが、限られた(安全な)HTMLを許可したい場合は、明らかにこのクラスから派生することはできません。あなたはより多くのプレゼンテーションオブジェクトのような音を記述している、まだIsDirtyとIsNewも同様にドメインモデルで使用することができるもの

0

。基本オブジェクトに何を含めるかを決定する前に、ビジネス要件が何であるかを明確に把握する必要があります。ビジネスオブジェクトにしばらく目を向けると、要件はどのくらい静的になりますか?オブジェクトがどのように相互作用するかを管理するすべてのルールを把握していますか?それらのルールは変更されますか?彼らが変わると、どのくらいの頻度で?これはあなたにとって最も挑戦的なことを証明するかもしれません。

あなたの仕事の大部分は、ビジネスプロセス、したがってCRUD機能のアーキテクチャの実装から来るべきであることがあります。重要なことですが、あなたの努力の焦点では​​ありません。つまり、ビジネスオブジェクトはビジネスプロセスの概念をサポートし、IsDirtyは含めません。データアクセスレイヤーは、レコードの状態に集中し、データの挿入または更新を行うかどうかを決定できます。

関連する問題