İş kurallarını saklamak için bir yapılandırma dosyası veya veritabanı kullanmalı mıyım?

Geçenlerde şunu ifade eden Pragmatik Programcı'yı okudum :

Ayrıntılar, bozulmamış kodumuzu karıştırıyor - özellikle de sık sık değişirse. İş mantığında veya yasada veya yönetimin günün kişisel zevklerinde bir miktar değişiklik yapmak için kod girmemiz ve kodu değiştirmemiz gerektiğinde, sistemi bozma riskini taşıyoruz - yeni bir hata getirme.

Avı Andrew; Thomas, David (1999-10-20). Pragmatik Programcı: Yolcudan Ustaya (Kindle Locations 2651-2653). Pearson Eğitimi (ABD). Kindle Sürümü.

Şu anda sadece bir dizi değerden olabilecek özelliklere sahip bazı modellere sahip bir web uygulamasını programlıyorum, örneğin (web uygulaması verisi gizli olarak gerçek bir örnek değil):

ışık-> tipi = küre / küp / silindir

Işık türü sadece yukarıdaki üç değer olabilir, ancak TPP'ye göre, değerlerini her zaman bir yapılandırma dosyasına yerleştirip koyabilecekmiş gibi kodlamalıyım. Uygulama boyunca bu birkaç olay olduğu için sorum şu:

Şunun gibi olası değerleri saklamalı mıyım:

• Bir yapılandırma dosyası:
  'light-types' => array(sphere, cube, cylinder),
'other-type' => value,
'etc' => etc-value

• Her config maddesi için bir satırlık veri tabanındaki tek bir tablo

• Her bir yapılandırma madde için bir tablo ile bir veritabanı (örneğin Tablo: light_types; sütun: id, name)

• başka bir yol mu?

Sunulan yardım / uzmanlık için çok teşekkürler.

Aynı soru üzerinde çalıştığım projelerin çoğunda da ortaya çıkıyor. Genellikle bunu yapıyorum:

1. Mümkün olan değer kümesinin yakın zamanda değişmesi muhtemel değilse, koddaki sınıf / arabirim sabitlerini veya kodlarını ve veritabanındaki numaralandırılabilir alanları kullanırım. Örnek: blog girişlerinin yayınlanma durumu: 'yayınlanmadı', 'denetleme altında', 'yayınlandı', vb.
2. Değerler muhtemelen değişecek, ancak değişiklikler program mantığını - config dosyalarını etkilemeyecektir. Örnek: "web sitemizi nasıl buldunuz?" çevrimiçi satın alma formundaki açılır listeye ilişkin seçenekler.
3. Değerlerin sık sık değişmesi ve / veya geliştiriciler tarafından düzenlenmemesi muhtemeldir, ancak yine de bu değişiklikler mantığı etkilemeyecektir - bir veritabanı veya en azından düzenleme için kullanıcı dostu bir arayüze sahip bir anahtar-değer depolama.
4. Değerleri değiştirmek mantığı etkileyecektir - muhtemelen sistemin yeniden tasarlanması gerekir (genellikle doğru) veya bazı iş kuralları motoruna ihtiyaç duyulur. Şimdiye kadar gördüğüm en zor vaka, meslektaşımın üzerinde çalıştığı psikolojik test kurucu oldu. Her test türü, basit ilaveden pozitif ve negatif değerlere sahip çoklu özellik skalasına ve hatta cevapların insan tarafından değerlendirilmesine kadar değişebilen kendi puanlama sistemine sahip olabilir. Bu proje hakkında biraz tartışma yaptıktan sonra, Lua'yı geliştirici olmayan kişilerin yeni testler oluşturma becerisiyle tamamen çelişen bir komut dosyası motoru olarak kullandık (Lua nispeten basit bir dil olsa da programcı olmayan bir kişi beklememelisiniz) öğrenecek).

TPP'den alıntı hakkında. Bence bozulmamış kodlar için doğru , ama gerçek hayatta basit bir işe başlasanız ( KISS prensibi ) ve gerçekten ihtiyaç duyulursa daha sonra özellikler eklemelisiniz ( YAGNI ).

Verileriniz bir veritabanında olacaksa, aynı DB'de bir 'light_types' tablosu olmasını öneririm. Bu size light-> type'ın sadece bu değerlerden biri olabileceği bir kısıtlamayı zorlamak için yabancı anahtarlar kullanma yeteneği verir, bu yüzden kod karışsa bile, DB'deki veriler daima geçerli olacaktır.

Veriler bir DB'de depolanmayacaksa, sadece bir demet numara için bir tane oluşturmak çok da işe yaramaz. Değerleri zor şekilde kodlamaktan kaçınmak istiyorsanız, bir yapılandırma dosyası önerebilirim.

(Ancak, zor kodlamadan kaçınmak için çok uzağa gitmemeye karşı uyarırdım. Önemsiz olmayan bir sistemde, yazarların farkına varmış olsun veya olmasın, iş kuralları ve gereklilikleri ile ilgili varsayımlar olacaktır. varsayımlar ve yazılım kodu kesinlikle her şeydir, temelde sadece bir "kural motoru", bir sistem içi ve / veya meta dili sistemi ile son bulursunuz ve meta dilinde bir sürü şey vardır. Kurallara uyun, herhangi bir işi kaydetmediniz veya herhangi bir esneklik kazanmadınız, sadece başka bir dil oluşturmak ve / veya öğrenmek zorunda kaldınız.

Şimdi, mevcut bir kural motoru bulmak ve kullanmak istiyorsanız, bu size biraz iş kurtarabilir (nereden depolayacağınız sorusunun yanıtlanmasıyla birlikte). Ama kendi işini kurmak iş yükünü iki katına çıkarır ve kaçınılmaz olarak, sana gerçekten iyi bir kural motoru yapmayı gerçekten bilmeyen insanlar tarafından inşa edilmiş, yarı gelişmiş bir sistem kazandırır.)

Genel olarak veriler için bir veritabanı kullanılmalı ve konfigürasyon için bir config dosyası kullanılmalıdır. (adından da anlaşılacağı gibi :)). Konfigürasyonun veritabanında tutulması endişelerin kötü bir şekilde ayrılmasıdır ve sadece haklı çıkarmak için iyi bir kullanım durumunuz varsa yapılmalıdır.

Ne kadar konfigürasyon kullanılacağına karar verirken ortaya çıkacak bir denge var. Config dosyalarınıza bir uygulamanın parçası kadar kod gibi davranmalısınız. Mümkün olduğunca kısa tutunuz. Uygulamaların, sihirli dizelerle dolu büyük bir xml dosyasıyla son bulduğunuz konfigürasyon kabiliyetinden muzdarip olması çok kolaydır.

Tarif etmeniz durumunda, hangi css dosyasının kullanılacağını tanımlamak için bir konfigürasyon elemanının bulunması makul olacaktır. (gereksinimler değişirse daha sonra sadece değiştirebilirsiniz). Config dosyasındaki her bir öğenin stilini yapılandırmak fazladan bir fikirdir.