सी # उपयोगकर्ता कॉन्फ़िगर करने योग्य डेटाबेस सेटिंग्स के लिए प्लगइन आर्किटेक्चर और संदर्भ

Question

मेरे पास एक डेटाबेस एप्लिकेशन है जो उपयोगकर्ता द्वारा कॉन्फ़िगर करने योग्य है - इनमें से कुछ विकल्प विभिन्न बाहरी प्लगइन सिस्टम से चयन कर रहे हैं।

मेरे पास बेस प्लगइन प्रकार है, मेरे डेटाबेस स्कीमा में एक ही फ़ील्ड के साथ एक ही प्लगइन रिकॉर्ड प्रकार है। मेरे पास एप्लिकेशन पर प्लगइन लोड करने के लिए PlugingMananger है (एक आईओसी कंटेनर के माध्यम से) शुरू करें और उन्हें डेटाबेस से लिंक करें (अनिवार्य रूप से फ़ील्ड को डेटाबेस पर डिस्क पर प्लगइन बनाते हैं)।

public interface IPlugin 
{ 
    Guid Id{ get; } 
    Version Version { get; } 
    string Name { get; } 
    string Description { get; } 
} 

प्लगइन्स तो PlugingMananger.GetPlugin(Guid pluginId, Guid userId), जहां यूजर आईडी कई उपयोगकर्ताओं को, जो एक प्लगइन कार्रवाई के लिए बुलाया जा सकता है में से एक का है का उपयोग कर प्राप्त किया जा सकता है।

प्लगइन ज्ञात इंटरफेस का एक सेट प्रत्येक निश्चित कार्य (फॉर्मेटर, बाहरी डेटा, डेटा प्रेषक इत्यादि) के लिए प्रत्येक विशिष्ट रूप से अग्रिम में घोषित किया गया है, यदि प्लगइन एक सेवा इंटरफ़ेस लागू करता है जिसे ज्ञात नहीं है तो इसे अनदेखा कर दिया जाएगा :

public interface IAccountsPlugin : IPlugin 
{ 
    IEnumerable<SyncDto> GetData(); 
    bool Init(); 
    bool Shutdown(); 
} 

प्लगइन्स भी सेटिंग हो सकती हैं विशेषताओं PluginSettingAttribute बहु उपयोगकर्ता प्रणाली में प्रति उपयोगकर्ता परिभाषित - इन गुणों जब एक प्लगइन एक विशिष्ट उपयोगकर्ता के लिए लिया गया है स्थापित कर रहे हैं, और एक PluginPropertyAttribute गुण जो सभी उपयोगकर्ताओं भर में आम हैं के लिए और प्लग-इन द्वारा केवल पढ़ने के लिए सेट करें जब प्लगइन एप्लिकेशन स्टार्टअप पर पंजीकृत होता है।

public class ExternalDataConnector : IAccountsPlugin 
{ 
    public IEnumerable<AccountSyncDto> GetData() { return null; } 
    public void Init() { } 
    public void Shutdown() { } 

    private string ExternalSystemUsername; 
    // PluginSettingAttribute will create a row in the settings table, settingId 
    // will be set to provided constructor parameter. this field will be written to 
    // when a plugin is retrieved by the plugin manager with the value for the 
    // requesting user that was retrieved from the database. 
    [PluginSetting("ExternalSystemUsernameSettingName")] 
    public string ExternalSystemUsername 
    { 
     get { return ExternalSystemUsername } 
     set { ExternalSystemUsername = value; } 
    } 

    // PluginPropertyAttribute will create a row in the attributes table common for all users 
    [PluginProperty("ShortCodeName")] 
    public string ShortCode 
    { 
     get { return "externaldata"; } 
    } 

    public Version PluginVersion 
    { 
     get { return new Version(1, 0, 0, 0); } 
    } 

    public string PluginName 
    { 
     get { return "Data connector"; } 
    } 

    public string PluginDescription 
    { 
     get { return "Connector for collecting data"; } 
    } 
} 

यहाँ मेरी सवाल और क्षेत्रों मैं पर मार्गदर्शन की मांग कर रहा हूँ कर रहे हैं:

1. डेटाबेस के लिए एक आईओसी कंटेनर में प्लग इन जोड़ने के ऊपर अमूर्त के साथ

   , उपयोगकर्ता डेटाबेस क्षेत्र Customer.ExternalAccountsPlugin = idOfExternalPlugin चुन सकते हैं। यह भारी लगता है - क्या कोई आसान तरीका है कि अन्य सिस्टम इसे प्राप्त करते हैं (उदाहरण के लिए SharePoint में कई डेटाबेस हैं जो उपयोगकर्ता डेटाबेस द्वारा संदर्भित हैं)?

2. मेरा आवेदन संकलन समय इंटरफेस है कि यह समर्थन करता है और अन्य सभी पर ध्यान नहीं देता पर तय - मैंने देखा है कुछ सिस्टम खुला प्लगइन्स जो मुझे लगता है शिथिल टाइप किया इंटरफेस और कास्टिंग के बहुत सारे मतलब होगा के साथ पूरी तरह विस्तार योग्य होने का दावा, है वहाँ एक दो विकल्पों के बीच आधा रास्ता जमीन जो भविष्य के अपडेट को बिना किसी संकलित किए जारी किए जाने की अनुमति देगी लेकिन फिर भी कंक्रीट इंटरफेस का उपयोग करेंगी?

3. मेरे प्लगइन्स में मेटाडाटा (प्लगइनप्रॉपर्टी या प्लगइनसेटिंग) हो सकता है और मैं इसे प्लग करने के लिए सबसे अच्छी जगह सुनिश्चित कर सकता हूं, या तो प्लगइन मेटाडेटा तालिका में (linq क्वेरी अधिक जटिल बना देगा) या प्लगइन डेटाबेस रिकॉर्ड पंक्ति में सीधे (आसान LINQ PluginManager.GetPluginsOfType<IAccounts>.Where(x => x.ShortCode = "externaldata").FirstOrDefault(); प्रश्नों, जो सबसे अच्छा अभ्यास के रूप में प्रयोग किया जाता है?

4. बाद प्लगइन्स क्षमताओं और इंटरफेस डेटाबेस स्कीमा पर इतना भारी भरोसा, सुझाया गया तरीका मैं एक विशिष्ट स्कीमा संशोधन के साथ प्रयोग के लिए एक प्लगइन सीमित कर सकते हैं क्या है? मैं रखना चाहेंगे डेटाबेस में सेटिंग्स तालिका में एक पंक्ति के रूप में यह स्कीमा संशोधन और प्रत्येक रिलीज के बाद इसे मैन्युअल रूप से अपडेट करें? क्या प्लगइन अधिकतम स्कीमा संस्करण का समर्थन करेगा, या एप्लिकेशन kn की सूची का समर्थन करेगा अपने प्लगइन संस्करण?

Answer 1

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

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

3) खैर, यह बहुत कुछ निर्भर करता है की है, नहीं? जब आप अपने डेटा को क्रमबद्ध करते हैं, तो आप एक रैपर बना सकते हैं जिसमें एक विशिष्ट प्लगइन, आईडी, मेटाडेटा और जो भी आप जरूरी निर्णय लेते हैं, के लिए सभी जानकारी शामिल हो। मैं उस तरह से जाऊंगा, क्योंकि इसे पुनर्प्राप्त करना आसान होगा, लेकिन क्या आपको इसकी आवश्यकता के लिए सबसे अच्छा तरीका है? अधिक जानकारी के बिना कहना मुश्किल है।

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

खैर ... कि 2 सेंट की मेरी लंबा संग्रह था।