Yapılandırma Sınıfı / Yapısı: Desen veya Anti-Pattern? Alternatifler?

Bir programa yeni yapılandırma seçenekleri eklerseniz, seçeneklerin gerçekleştirilmesi gereken yerlere ulaşması açısından tonlarca dalgalanma etkisi olabilir. Bununla başa çıkmanın üç temel yolu var:

1. Tüm yapılandırma ayarlarını programınızın açıkça ilkel olarak ihtiyaç duyan kısımlarına iletin. Bu, en açık yol ve şeyleri en çok birbirinden ayıran yöntemdir. Dezavantajı, bunun hem ayrıntılı hem de kırılgan olmasıdır.

2. En sık kullanılan yapılandırma ayarlarını genel / statik yapın. Bu en basit yoldur, ancak uzaktan işlem yapar, test edilebilirliği engeller ve yapılandırmanın gerçekten küresel olduğunu varsayar (herhangi bir zamanda yalnızca bir yapılandırma isteyeceksiniz).

3. Tüm program için veya programdaki her önemli sorun için tüm yapılandırma seçeneklerini içeren bir yapılandırma sınıfı / yapısı oluşturun ve ardından bunu açıkça iletin. Bu, (1) 'den daha az açık ancak (2)' den daha açıktır. Yalnızca bir işlev çağrısı için bir ayarı değiştirmek isterseniz, yapılandırma nesnesini klonlayabilir ve bu bir değeri değiştirebilirsiniz. Bu hem testte hem de pratikte kullanışlıdır. Bununla birlikte, potansiyel olarak tonlarca bilgiyi ihtiyaç duymadığı bir işleve geçirirsiniz ve config sınıfında / yapıda bir değeri değiştirmek yine de uzaktan harekete neden olabilir.

(3) bir örüntü mü yoksa anti-örüntü mü düşünürdünüz? Bu bir anti-desense, bunun yerine ne yaparsınız?

En iyi çözüm, birkaç yapılandırma arabirimi yapmak ve bunları istediğiniz gibi uygulamak olacaktır. Bu hem erişilebilirliği sınırlar hem de işleri yerel tutar. Ancak, tüm yapılandırmayı tek bir sınıfta chucking ve çok daha fazla gravitasyona sahip bir soruna geçmeye değer. Bu yapılandırma, UtterlyCrucialAlwaysChangingClass değil - hemen hemen aynı kalacak. Hepsini küresel hale getirmediğiniz ve uygulama tutarlı olduğu sürece, bu konuda endişelenmeyeceğim.

1. seçiminizi tercih ederim, çünkü ayırma daha kolay test yapılmasını sağlar ve nesnenin bağlı olduğu yapılandırma ayarları açıkça yapılır. Bir nesne bir yapılandırma ayarı gerektiriyorsa, bunu bir yapıcı argümanı veya ayarlayıcı yöntemiyle açıkça nesneye sağlayın. Bu yapılandırma ayarlarını nesneye enjekte etmek için bir bağımlılık enjeksiyon çerçevesi kullanarak ayrıntı düzeyini azaltın.

Yapılandırma dosyanızın XML ile yazılmış olup olmadığını düşünün. Daha sonra, bu XML'in parçalarını bileşenlerinizin her birine iletebilirsiniz, böylece yapılandırma verilerini alırlar.

.NET kullanıyorsanız, XmlSerialiser kullanarak yapılandırmanız Xml'den bir nesne hiyerarşisi oluşturmak ve bu nesneleri yapılandırma olarak iletmek için DataContracts ile sınıflar oluşturabilirsiniz.

Bu sizi bir sonraki soruna tanıtır. Yapılandırma verilerinizde üç farklı bölüm vardır. Kod kitaplıklarınızı bu ürün gibi davranacak şekilde düzenleyen yapısal uygulama yapılandırması. Yüklemeye özgü ayarlarınızı ve sisteminizdeki her kullanıcıya göre değişen Kullanıcı tercihi / ayar verilerini içeren site yapılandırma ayarları.

Hangi bölümün hangisi olduğunu bilmek ve bu veri ayarlarını ayrı tutmak güncellemeleri yüklemeyi çok daha kolay hale getirecektir (müşteri ayarlarını kaybetmeden)

3 numaralı seçenekteki sınıfı statik hale getirirdim. Yani yerine

//create SomeCl
Foo f = new Foo();
f.setConfigInst(cfg);
...
...
//Inside Foo
public void setConfig(MyAppConfig c) { localCfg = c; }
...
//somewhere else:
x = localCfg.getConfigForX();

Sadece sahip olabilirsiniz:

//Inside Foo
x = MyAppConfig.getConfigForX();

Yapılandırma verilerini yükleme / kaydetme ayrıntılarının MyAppConfigsınıf içinde olmasına izin verin . Ve elbette, farklı amaçlar için farklı sınıflar gibi daha karmaşık varyasyonlara sahip olabilirsiniz.

Bu yaklaşımın bir sorun olacağı tek durum, herhangi bir nedenle, farklı konfigürasyonların birden fazla örneği üzerinde aynı anda çalışmanız gerekiyorsa , ancak henüz böyle bir durumla karşılaşmamamdı.

"3 katman (arayüz, iş mantığı, veri erişimi)" yaklaşımını kullandığımız bir proje üzerinde çalışıyorum. Uygulama çok kullanıcılı bir web sunucusu veya istemci sunucusu olabilir.

Kullanıcının çalıştığı PC'ye özgü 3 farklı konfigürasyonla çalışıyoruz. Geçerli kullanıcı için ikinci özellik ve tüm kullanıcılar ve istemci uygulamaları için üçüncü genel yapılandırma.

Her yapılandırma, uygulamanın her kurulumunda bir nesne ile temsil edilir.

Bu yaklaşım projenize yardımcı olabilir.