वैश्विक एप्लिकेशन सेटिंग्स तक पहुंच

एक डेटाबेस एप्लिकेशन जिसे मैं वर्तमान में काम कर रहा हूं, डेटाबेस में सभी प्रकार की सेटिंग्स स्टोर करता है। उनमें से अधिकतर सेटिंग्स कुछ व्यावसायिक नियमों को अनुकूलित करने के लिए हैं, लेकिन वहां कुछ अन्य सामान भी हैं।

ऐप में ऐसी ऑब्जेक्ट्स होती हैं जो विशेष रूप से एक निश्चित कार्य करती हैं, उदाहरण के लिए, एक निश्चित जटिल गणना। उन गैर-यूआई ऑब्जेक्ट्स यूनिट-परीक्षण हैं, लेकिन उन वैश्विक सेटिंग्स तक पहुंच की भी आवश्यकता है। जिस तरह से हमने इसे अभी लागू किया है, वह ऑब्जेक्ट गुणों को देकर है जो रनटाइम पर एप्लिकेशन कंट्रोलर द्वारा भरे हुए हैं। परीक्षण करते समय, हम परीक्षण में वस्तुओं को बनाते हैं और परीक्षण के लिए मूल्यों को भरते हैं (डेटाबेस से नहीं)।

यह बेहतर काम करता है, किसी भी मामले में उन सभी वस्तुओं को कुछ वैश्विक सेटिंग्स ऑब्जेक्ट की आवश्यकता होती है --- यह निश्चित रूप से यूनिट परीक्षण को असंभव बनाता है :) नुकसान यह हो सकता है कि आपको कभी-कभी दर्जन सेट करने की आवश्यकता हो गुणों के, या आपको उन गुणों को उप-वस्तुओं में 'percolate' करने की आवश्यकता है।

So the general question is: how do you provide access to global application settings in your projects, without the need for global variables, while still being able to unit test your code? This must be a problem that's been solved 100's of times...

(ध्यान दें: मैं एक अनुभवी प्रोग्रामर का अधिक नहीं हूं, जैसा आपने देखा होगा, लेकिन मुझे सीखना अच्छा लगता है! और निश्चित रूप से, मैंने पहले ही इस विषय में शोध किया है, लेकिन मैं वास्तव में कुछ पहले की तलाश में हूं अनुभवों के अनुभव)

 0
जोड़ा संपादित
विचारों: 10
स्रोत

4 उत्तर

आमतौर पर यह एक आईएनआई फ़ाइल या एक्सएमएल विन्यास फाइल द्वारा संभाला जाता है। फिर आपके पास सिर्फ एक कक्षा है जो नींद के दौरान सेटिंग पढ़ती है।

.NET ने इसे कॉन्फ़िगरेशन मैनेजर क्लास के साथ बनाया है, लेकिन इसे कार्यान्वित करना काफी आसान है, बस टेक्स्ट फाइलें पढ़ें, या एक्सएमएल को डीओएम में लोड करें या कोड में हाथ से पार्स करें।

डेटाबेस में कॉन्फ़िगरेशन फाइलें ठीक है, लेकिन यह आपको डेटाबेस से जोड़ती है, और आपके ऐप के लिए अतिरिक्त निर्भरता बनाती है जो ini/xml फ़ाइलों को हल करती है।

0
जोड़ा
स्रोत

इसे मैने किया है:

public class MySettings
{
    public static double Setting1
        { get { return SettingsCache.Instance.GetDouble("Setting1"); } }

    public static string Setting2
        { get { return SettingsCache.Instance.GetString("Setting2"); } }
}

परिपत्र निर्भरताओं के साथ किसी भी मुद्दे को हटाने के लिए मैंने इसे एक अलग आधारभूत संरचना मॉड्यूल में रखा।
ऐसा करने से मैं किसी भी विशिष्ट विन्यास विधि से बंधे नहीं हूं, और मेरे अनुप्रयोग कोड में कोई स्ट्रिंग चल रहा है।

0
जोड़ा
स्रोत

मैं सेवा लोकेटर पैटर्न से मेरी कॉन्फ़िगरेशन पहुंच को मॉडल करना चाहता हूं। यह मुझे किसी भी कॉन्फ़िगरेशन मान को प्राप्त करने के लिए एक बिंदु देता है जो मुझे चाहिए और इसे एक अलग पुस्तकालय में एप्लिकेशन के बाहर डालने से, यह पुन: उपयोग और परीक्षण योग्यता की अनुमति देता है। यहां कुछ नमूना कोड दिया गया है, मुझे यकीन नहीं है कि आप किस भाषा का उपयोग कर रहे हैं, लेकिन मैंने इसे सी # में लिखा है।

सबसे पहले मैं एक सामान्य वर्ग बनाता हूं जो मेरे कॉन्फ़िगरेशन इटिम मॉडल करेगा।

public class ConfigurationItem
{
    private T item;

    public ConfigurationItem(T item)
    {
        this.item = item;
    }

    public T GetValue()
    {
        return item;
    }
}

फिर मैं एक वर्ग बनाता हूं जो कॉन्फ़िगरेशन आइटम के लिए सार्वजनिक स्थैतिक रीडोनली चर का खुलासा करता है। यहां मैं सिर्फ एक कॉन्फ़िगरेशन फ़ाइल से ConnectionStringSettings पढ़ रहा हूं, जो सिर्फ xml है। बेशक अधिक वस्तुओं के लिए, आप किसी भी स्रोत से मूल्यों को पढ़ सकते हैं।

public class ConfigurationItems
{
    public static ConfigurationItem ConnectionSettings = new ConfigurationItem(RetrieveConnectionString());

    private static ConnectionStringSettings RetrieveConnectionString()
    {
       //In .Net, we store our connection string in the application/web config file.
       //We can access those values through the ConfigurationManager class.
        return ConfigurationManager.ConnectionStrings[ConfigurationManager.AppSettings["ConnectionKey"]];
    }
}

फिर जब मुझे उपयोग के लिए कॉन्फ़िगरेशनइटम की आवश्यकता होती है, तो मैं इसे इस तरह कहते हैं:

ConfigurationItems.ConnectionSettings.GetValue();

और यह मुझे एक प्रकार का सुरक्षित मूल्य वापस कर देगा, जिसे मैं तब भी कैश कर सकता हूं या जो कुछ भी चाहता हूं उसे कर सकता हूं।

नमूना परीक्षण यहां दिया गया है:

[TestFixture]
public class ConfigurationItemsTest
{
    [Test]
    public void ShouldBeAbleToAccessConnectionStringSettings()
    {
        ConnectionStringSettings item = ConfigurationItems.ConnectionSettings.GetValue();
        Assert.IsNotNull(item);
    }
}

उम्मीद है की यह मदद करेगा।

0
जोड़ा
स्रोत

आप मार्टिन फाउलर्स सर्विस लोकेटर पैटर्न का उपयोग कर सकते हैं। PHP में यह ऐसा दिखाई दे सकता है:

class ServiceLocator {
  private static $soleInstance;
  private $globalSettings;

  public static function load($locator) {
    self::$soleInstance = $locator;
  }

  public static function globalSettings() {
    if (!isset(self::$soleInstance->globalSettings)) {
      self::$soleInstance->setGlobalSettings(new GlobalSettings());
    }
    return self::$soleInstance->globalSettings;
  }
}

आपका उत्पादन कोड तब सेवा लोकेटर को इस तरह शुरू करता है:

ServiceLocator::load(new ServiceLocator());

अपने टेस्ट-कोड में, आप इस तरह अपनी नकली सेटिंग्स डालते हैं:

ServiceLocator s = new ServiceLocator();
s->setGlobalSettings(new MockGlobalSettings());
ServiceLocator::load(s);

यह सिंगलेट्स के लिए एक भंडार है जिसे परीक्षण उद्देश्यों के लिए आदान-प्रदान किया जा सकता है।

0
जोड़ा
स्रोत