Kullanıcı arabirimi (veya diğer) özelliklerini tarih-kod kokusuna göre açıp kapatmak mı?

ASP.NET 2.0'da yazılmış, bazı işlevler eklememiz gereken korkunç bir sistemimiz var. Sorun, belirli bir ürünün belirli bir tarihten sonra başlatılan (ve diğerleri kapandığı) işletme için açılması gereken kullanıcı arayüzü özelliklerine sahip olması ve sayfanın mevcut işletme için aynı görünmesi gerektiğidir.

Tarih tabanlı JavaScript kullanıcı arayüzü anahtarları fikrini içgüdüsel olarak bulduğumdan ve eski ve yeni işletmenin "düzensiz" olması için web kontrollerinin karıştırılmasında (daha iyi bir kelime istemek için) sayfanın yeni bir işletme için yeniden yazılması için bastırıyorum ).

Zamana dayalı UI özelliklerine sahip olma uygulaması yaygın olarak kabul gören bir uygulamadır ve eğer değilse, bu hareket tarzını izlemenin bilinen riskleri nelerdir?

Bir müşteri için hangi özelliklerin etkinleştirildiğine veya hangi dağıtım türlerini seçtiklerine bağlı olarak bir kullanıcı arayüzünü değiştirmenin yanlış bir yanı yoktur, ancak değişiklik

1. anlamlı bayraklara bağlıdır, örneğin, bir dışa aktarma seçeneğini etkinleştirmek / devre dışı bırakmak için "HAVE_EXPORT", garip tarih karşılaştırmaları yerine. UI'nin ne zaman yayınlandığına ilişkin iş kuralını bilen bir işi yoktur, yalnızca UI görevini yerine getirmeli ve UI'ya özgü talimatlara uymalıdır.
2. Sunucu tarafında kontrol sahibi olun, böylece müşteri ödemediği özellikleri gizlice etkinleştiremez.

(Not tersi olduğunu - dis Belirli bir süre sonra abling özellikler - hayır-hayır yaptığınızı açıkça bir zaman sınırlı deneme sürümü satıyorsanız bildirmiştik ettik sürece önemli olduğu böyle oluşturuluyor. Zaman bomba insanlar nefret yapacak başka koşullar altında neredeyse her şeyden daha hızlı.)

Gereklilik kendisi sorunlu değil, ama iyi ve kötü yolları vardır uygulamak onu. Aşağıdaki gibi bir yere kopyalayıp yapıştırdığınız bir kod varsa:

if (businessInitiationDate > cutoffDate)
  enableNewControlsForThisOneLittlePiece();
else
  enableOldControlsForThisOneLittlePiece();

Şu anda daha hızlı görünse bile, bunu sürdürmek çılgınca olacak. Örneğin, belki bir noktada bazı eski müşteriler yeni görünümü isteyecektir. Belki bir noktada kendi kesim tarihine sahip üçüncü bir konfigürasyon olacaktır.

İdeal olarak, eğer bu ifadenin tam olarak kodunuzda, tercihen sunucu tarafında bir kez görünmesini istersiniz . Ancak, tüm uygulamayı çoğaltmaktan ve değişiklik yapmaktan da kaçınmak istersiniz. Ortak kodu bulun ve hesaba katın, ardından yalnızca farklı parçalar için küçük ayrı işlevler oluşturun. Ardından bu işlevleri tek bir merkezi yerden etkinleştirin veya devre dışı bırakın.

Bu bir gerekliliktir ve kötü kokulu görünse de - temel olarak datetime değerine dayalı yapılandırma - UI'nizi değiştirmek için zamanın kullanılamamasının bir nedeni yoktur. Klasik kasa, gündüz parlak renklerden gece karanlık bir temaya değişen bir satnav ekran (ve gerçekten adanmışsanız, aralarında sessiz bir renk).

Ancak, bir iyileştirme olarak önerebileceğim bir şey, denetimleri etkinleştiren bir tarih kavramını, ancak sürüm numarasını kaldırmaktır. Sürüm, UI yapılandırmasını ayarlar (yani NewCustomer için yapılandırılmış söyleyecek bir bayrağınız vardır ve gelecekte NewNewCustomer'ın istediği ek kontrolleri karşılamak için genişletilebilir). Bu kodu işlemek çok daha kolaydır ve çok daha güzel kokar.

Daha sonra, sürüm numarasını bazı kriterlere göre ayarlayan yalnızca 1 sorununuz var ve bu, bugün bir tarih kontrolü, muhtemelen daha sonra sunucu tarafı yapılandırma seçeneği veya hatta bir süre içinde kullanıcı girişi ile ayarlanan bir çerezle yapılabilir. gelecek.

Bu, daha genel bir sorunun özel bir örneği gibi geliyor: Önceden tanımlanmış kurallara göre UI özelliklerini belirli nedenlerle devre dışı bırakmak kötü bir uygulama mı? O zaman cevap "elbette hayır" dır. Özellikle tarih teslimi zor olabilir, çünkü tarihler ve saatler zordur , ancak genel prensipte, iş gereksinimlerinizin gerektirdiği durumlarda bunu yapmanın iyi bir nedeni yoktur.

Değişikliklerin tarihe duyarlı belirli bir iş amacı ile ilgisi varsa, bu gerekli bir kötülüktür.

Bu, programı kalıcı olarak değiştirecek bir revizyonu dağıtmakla ilgiliyse ve eski tasarım bir daha asla kullanılmayacaksa, bir güncellemeyi doğru zamanda dağıtmak daha iyidir.

Kulağa hoş geliyor. Kullanıcı arayüzünün farklı kullanıcılara uyarlanması oldukça yaygındır, örneğin burada yığın akışı üzerinde farklı özellikler tek bir kullanıcının karmasına bağlı olarak etkinleştirilir veya devre dışı bırakılır.

Beğenmemenizin nedeni, herkesin aynı kullanıcı arayüzünü gördüğü bir çözüme göre açıkça karmaşıklık katmasıdır. Ancak, karmaşıklık temel karmaşıklık gibi görünmektedir . kötü bir mimari kararın bir ürünü değil, bir iş gereksinimi. Tabii ki bir maliyeti olacak (ki iş ile iletişim kurmalısınız), ancak işletme maliyete değer olduğuna karar verirse, bunu uygulamaya devam edersiniz.

Bilinen riskler: En büyük risk, muhtemelen çeşitli yapılandırmalarda kullanıcı arayüzünü test ettirmektir. Çeşitli kullanıcı grupları için kullanıcı arayüzü özelliklerini etkinleştirme / devre dışı bırakma yolunda ilerlemeye başlarsanız, olası yapılandırmalarda hızlı bir patlama elde edebilirsiniz.

Ayrıca, iş mantığı katmanındaki kısıtlamaları uyguladığınızdan emin olmalısınız, böylece kullanıcı ilk etapta mümkün olmasa bile müşterilerin izin verilmeyen işlemleri gerçekleştiremediğini doğrulamalısınız:

Açıkladığınız şey, etkili bir buluşma kavramıdır , bu kesinlikle yeni bir fikir değildir ve özünde, zamansal bir kalıp uygulayabileceğiniz bir tür zamansal problemdir .

Temel olarak veritabanınızda yapacağınız şey, form modülleri veya form sürümlerine (burada bileşenler olarak adlandırılır) etkili bir tarih uygulamak ve bu bileşenler ve bunların etkin başlangıç ​​/ bitiş tarihleri ​​hakkında bazı meta veriler depolamaktır. Tabii ki uygulamada kullanıcılarınız hakkında da bazı verilere ihtiyacınız olacak.

Bu uygulamayı yeniden yazmayı düşünmek için başka daha zorlayıcı nedenleriniz olabilir. Etkili buluşma sorunları tek sorunlarınızsa, belki de etkili buluşmanın daha iyi bir seçenek olduğunu öneririm. Değilse, bunu senaryonuza göre değerlendirmeniz gerekir.

Bu, tarihe dayalı etkinleştirme ile tamamen geçerli olan bir özellik geçişidir. Özelliğin yalnızca tanıtım döneminde mi kullanıldığını veya yeni bir hükümet düzenlemesinin belirli bir tarihte başladığında sona ermesi gerektiğini düşünün.

APS.NET ve JavaScript'te çalışıyorsunuz, ancak Java özellik değiştirme çerçeve çalışması Togglz özellikle tarih (ve saat!) Tabanlı bir etkinleştirme kuralına sahip .