をリファクタリング。 UI配線と一緒にビジネスロジックが絡み合っているのは明らかです。私はそれらを分ける最善の方法が分からないだけです。は、私は、次の簡単な関数を持って有効/無効ボタンのトグル機能
小さなコンテキストを与えるために、関数はフォームの3つの場所から呼び出されます。 _uosDepositorFrequencyは、ボタンが2つしかないラジオボタングループです。
アイデア？
更新：
[OK]を、多分私が思ったほど明白ではありません。ビジネスルールは、雇用者が半期預金を行う場合（_uosDepositorFrequency.Value = 0）、スケジュールBフォームに記入する必要があると規定しています。
まず、私の質問に答えたすべての人に感謝したいと思います。
私はこれに取り組んでいましたが、私は解決策を考え出しました。
最初にパブリックプロパティとして_uosDepositorFrequency.Valueと_btnScheduleB.Enabledを公開し、ビューインターフェイスを更新しました。預託頻度の列挙型を定義するのに少し時間がかかりました。
public bool EnableScheduleB
{
get
{
return _btnScheduleB.Enabled;
}
set
{
_btnScheduleB.Enabled = value;
}
}
public DepositFrequency DepositorFrequency
{
get
{
return (DepositFrequency)_uosDepositorFrequency.Value;
}
set
{
_uosDepositorFrequency.Value = (int)value;
}
}
は、その後、私は私のプレゼンターに元の関数の本体をコピーして、私が作成したプロパティを使用するように変更しました。 _uosDepositorFrequencyコントロールが他の場所で初期化されているため、元の関数のnullチェックが不要になりました。
public void UpdateScheduleBStatus()
{
ReturnView.EnableScheduleB = ReturnView.DepositorFrequency == DepositFrequency.Semiweekly;
}
最後に_uosDepositorFrequency_ValueChangedイベントハンドラがUpdateScheduleBStatusを呼び出すように更新されました。
private void _uosDepositorFrequency_ValueChanged(object sender, System.EventArgs e)
{
Presenter.UpdateScheduleBStatus();
}
コメント歓迎。
私はビジネスロジックではないと思います。私のUIロジックのように見えます。私はそれを変更しません。
私がwpfを使用していたとしても、有効な状態をデータにバインドします。
多分、私は何かが欠けているかもしれませんが、そこにビジネスロジックがあるかどうかわかりません。フォーム上の別のコントロールに値があるかどうかに基づいてボタンを有効/無効にするだけです。私はこの方法をリファクタリングする必要性を見ません、それは私にすべての視点の論理です。
UIロジックとビジネスルールが混同されているようです。あなたが持っているコードはUIロジックであり、リファクタリングすべきではありません。あなたが言っているビジネスルールは、の値が0の場合、ユーザーはフォームに記入する必要があります。ビジネスロジックは、ユーザが続行する前に_btnScheduleBが有効になっているときに記入済みの書式を持つようにする必要があります。
プレゼンター：
if(this._uosDepositorFrequency.Value > 0) //int objects cannot be null
ViewData["ScheduleBRequired"] = true;
ビュー：それは、これが満たされるべきであること、businessrequirementある場合
private void Draw()
{
if ((bool)ViewData["ScheduleBRequired"]){
this._btnScheduleB.Enabled = true;
this._validatorScheduleB.Active = true; //required data should be checked clientside with js
}
}
は、それがプレゼンターによってトリガされなければなりません。 uiは、発表者の決定に従う責任があります。例えばScheduleBを必要とするかどうかを指定します。
ラジオコントロールのモデルを変更するための選択肢が変更されました（これは、Employerエンティティです）。 UIが加入している何らかの種類のDepositorChangedイベントを発生させ、それに応じてスケジュールボタンを有効/無効にします。 Observerパターン、多かれ少なかれ。上記の方法では複雑さが増し、これをUIコードに残しておくことをお勧めします（コメントを追加するか、中間ブール変数を使用して読者に意図を伝えることをお勧めします）。特にこれが唯一の場所であれば、ルールが使用されています。
コードに関する副作用：クラスフィールドの先頭にアンダースコアを付けたり、代わりにthis.を使用するのは宗教的な議論です。私は誰もが両方を使用することは冗長であることに同意すると思います...
ねえ、私は知っています。このプロジェクトは他の企業が所有していたので、チームはコーディング基準に同意できないと思います。私はこれを見つけたらこれを掃除してきた。 –
これは他の人が指摘しているように、UIの整合性を維持しているため、実際にはビジネスロジックではありません。あなたはこのようなnullチェックを削除することができます。
this._btnScheduleB.Enabled = (int)(this._uosDepositorFrequency.Value ?? 0) == 0;
@Dave：コードはオリジナルと100％同等ではありません。 Valueがnullの場合、元のコードはボタンの有効な状態を変更しません。しかし、それはうまくいくかもしれません、ポスターは文脈をよく知っています。 –
それが現在の形式では意味がありませんでした本当にをない限り、私は、コードの2行をリファクタリングについてはあまり心配しないでしょう。
すべてのビジネスルールをUIレイヤーから移動する必要が本当にありますか？これは通常、複雑さが増し、時には周囲に広がる論理（特にあなたが見せている種類の論理）で生活する価値があります... –
ビジネスルールを分離しているのは、フォームが作成されるためです置き換えられたが、ルールはまだ残っている。 –
十分に公正。私は以下の答えであなたに一つの選択肢を与えました。しかし、個人的に私はそれをそのまま残し、置き換えをしている人のためにコメントしています。一般に、複数のUI間でビジネスルールを共有する場合にのみ意味があります。 –