日付に基づいてUI（またはその他の）機能のオンとオフを切り替えていますか？コードのにおいですか？
いくつかの機能を追加する必要があるASP.NET 2.0で作成された恐ろしいシステムがあります。問題は、特定の製品のUI機能が特定の日付以降に開始されたビジネスではオンにする必要がある（そして他の製品ではオフになる）一方で、既存のビジネスではページが同じように表示される必要があることです。
私は直感的に日付ベースのJavaScript UIスイッチのアイデアを見つけ、古いビジネスと新しいビジネスのWebコントロールの混合を「ばかげた」ものにする（より優れたWordが必要なため） ）。
時間ベースのUIを使用する慣習は、広く受け入れられている慣行を特徴としていますか？そうでない場合、その一連の行動を追求する既知のリスクは何ですか？
お客様に対して有効になっている機能、またはお客様が選択した展開タイプに基づいてUIを微調整しても問題はありませんが、変更により
- 意味のあるフラグに依存します。 "HAVE_EXPORT"は、奇妙な日付の比較ではなく、エクスポートオプションを有効/無効にします。 UIには、何がいつ公開されたかに関するビジネスルールを知っているビジネスはなく、UIタスクのみを実行し、UI固有の指示に従う必要があります。
- 顧客が未払いの機能を不正に有効化できないように、サーバー側で管理されている。
（反対のdis特定の時間の後に機能を有効にする-は、期間限定の試用版を販売していることを明確に伝えない限り、大きな問題ではないことに注意してください。そのような作成時限爆弾他の状況下では、人々はあなたをほとんど何よりも速く憎むようになります。）
要件自体には問題はありませんが、要件を実装するための良い方法と悪い方法があります。次のような場所にコードをコピーして貼り付けた場合：
if (businessInitiationDate > cutoffDate)
enableNewControlsForThisOneLittlePiece();
else
enableOldControlsForThisOneLittlePiece();
たとえそれが今のところもっと速いように思えても、それを維持するのは大変です。たとえば、おそらくある時点で、一部の古い顧客は新しい外観を望んでいるでしょう。たぶん、ある時点で、独自の締切日を持つ3番目の構成が存在するでしょう。
理想的には、このifステートメントをコード内に表示する1回だけをサーバー側に表示するのが理想的です。ただし、アプリケーション全体を複製して変更を加えることも避けたいです。共通のコードを見つけてそれを因数分解してから、異なる部分だけに小さな個別の関数を作成します。次に、これらの機能を1つの場所から有効または無効にします。
これは要件であり、臭いのように見えますが、基本的には日時値に基づく構成ですが、UIを変更するために時間を使用できない理由はありません。古典的なケースは、昼間の明るい色から夜の暗いテーマに変化するsatnavディスプレイです（そして、本当に熱心な場合は、中間の色が落ち着きます）。
ただし、改善として提案できることの1つは、コントロールを有効にする日付の概念を削除することですが、バージョン番号は削除します。このバージョンはUI構成を設定します（つまり、NewCustomer用に構成済みと言うフラグがあり、将来的にはNewNewCustomerが必要とする追加のコントロールに対応するように拡張できるなど）。これはコードで処理するのがはるかに簡単で、匂いがずっといいです。
次に、いくつかの基準に基づいてバージョン番号を設定する問題が1つだけあります。これは、今日の日付チェック、後でサーバー側の構成オプション、またはユーザーのログインで設定されたCookieで実行できます。未来。
これは、より一般的な質問の特別なケースのように感じられます。事前定義されたルールに従って特定の理由でUI機能を無効にすることは悪い習慣ですか？ですから、答えは「もちろんありません」です。 日付と時刻は難しい であるため、特に日付の扱いは難しい場合がありますが、一般的な原則として、ビジネス要件で要求されている場合にそれを行わない理由はありません。
変更が日付に依存する特定のビジネス目的に関係している場合、それは必要な悪です。
これが、プログラムを永続的に変更するリビジョンをプログラムに展開することであり、古い設計が二度と使用されない場合は、更新を適切なタイミングで展開することをお勧めします。
いいですね。 UIをさまざまなユーザーに適応させることは非常に一般的です。ここで、stackoverflowでは、個々のユーザーのカルマに基づいてさまざまな機能が有効または無効になります。
それが嫌いな理由は、誰もが同じUIを見るソリューションに比べて明らかに複雑になるためです。ただし、複雑さは本質的な複雑さ、つまりこれはビジネス要件であり、アーキテクチャの決定が悪いことによるものではありません。もちろん、コストはかかります（ビジネスに伝える必要があります）が、ビジネスがコストに見合うと判断した場合は、実装を進めます。
既知のリスク：最大のリスクは、さまざまな構成でUIをテストすることです。さまざまなユーザーグループのUI機能の有効化/無効化の道を進んでいくと、考えられる構成が急増する可能性があります。
また、ビジネスロジックレイヤーに制限を実装することを確認する必要があります。これにより、UIで最初から許可されていなくても、許可されていない操作を顧客が実行できないことを確認できます。
あなたが説明しているのは、効果的なデートの概念です。これは決して斬新なアイデアではなく、その核となるあなたが適用できる一時的な問題のタイプです 時間的パターン 。
基本的にデータベースで行うことは、フォームmodulesまたはフォームversions（以下、コンポーネントと呼びます）のいずれかに有効日を適用することです）、これらのコンポーネントとそれらの有効な開始/終了日に関するいくつかのメタデータを保存します。もちろん、アプリケーション内のユーザーに関するいくつかのデータも必要です。
このアプリケーションを書き直すことを検討する他の説得力のある理由があるかもしれません。効果的なデートの問題が唯一の問題である場合は、おそらく効果的なデートを実装することをお勧めします。そうでない場合は、シナリオに基づいて評価する必要があります。
これは、日付に基づいてアクティブ化される機能トグルです。これは完全に有効です。この機能がプロモーション期間中にのみ使用されるものだったのか、または特定の日付に新しい政府規制が発動したときに終了しなければならなかったと想像してください。
APS.NETとJavaScriptで作業していますが、Java feature-toggle frame work Togglzには具体的に 日付（および時刻！）ベースのアクティベーションルール があります。