Dependencyinjection: पुनरावर्ती रिज़ॉल्यूशन को रोककर सेवाओं को एक-दूसरे को सजाने दें

को निर्मित 18 दिस॰ 2015 · 31टिप्पणियाँ · स्रोत: aspnet/DependencyInjection

उपयोगकर्ता कहानी / केस परिदृश्य का उपयोग करें

एक डेवलपर के रूप में, मैं पहले से पंजीकृत सेवा को किसी अन्य सेवा के साथ लपेटकर विस्तारित करना चाहता हूं जो समान इंटरफ़ेस को उजागर करता है।

देखें: https://github.com/aspnet/Mvc/issues/3739

उदाहरण इंटरफ़ेस और कार्यान्वयन

public interface IMyService
{
    void DoSomething();
}

public partial class DefaultMyService
{
    public partial void DoSomething();
}

public partial class DecoratorForMyService
{
    private IMyService decorated;

    public DecoratorForMyService(IMyService decorated)
    {
        this.decorated = decorated;
    }

    public partial void DoSomething();
}

सेवा संग्रह स्थापित करने के तरीकों के उदाहरण

कंस्ट्रक्टर रिज़ॉल्यूशन का उपयोग करना

var collection = new ServiceCollection();
collection.AddTransient<IMyService, DefaultMyService>();
collection.AddTransient<IMyService, DecoratorForMyService>();
var provider = collection.BuildServiceProvider();
var service = collection.GetService<IMyService>(); // Returns the constructed DecoratorForMyService

कार्यान्वयन कारखानों का उपयोग करना

var collection = new ServiceCollection();
collection.AddTransient<IMyService, DefaultMyService>();
collection.AddTransient<IMyService>(_provider =>
{
    // Returns the previously registered IMyService.
    // Calling _provider.GetService<IEnumerable<IMyService>>() here
    // would return a collection containing all registered IMyServices
    // except for this one.
    var decorated = _provider.GetService<IMyService>(); 
    return new DecoratorForMyService(decorated);
});
var provider = collection.BuildServiceProvider();
var service = collection.GetService<IMyService>(); // Returns the constructed DecoratorForMyService

व्यवहार संबंधी विचार

वर्तमान में, उपरोक्त दो दृष्टिकोणों के परिणामस्वरूप क्रमशः 'परिपत्र निर्भरता' अपवाद और StackOverflowException होता है। एक कार्यान्वयन जो उपरोक्त परिदृश्यों के लिए अनुमति देता है, प्रभावी रूप से StackOverflowException पूरी तरह से रोक देगा, और 'सर्कुलर डिपेंडेंसी' अपवाद को तभी फेंकेगा जब उस प्रकार के लिए कोई अन्य पहले से पंजीकृत सेवाएं नहीं हैं जिसे हल किया जा रहा है जिसके परिणामस्वरूप सर्कुलर निर्भरता परिदृश्य फेंक रहे हैं "सेवा को हल करने में असमर्थ ..." प्रकार का अपवाद, जो अपने आप में उन मामलों के लिए परिपत्र को पर्याप्त रूप से व्यक्त करना चाहिए।

स्रोत

tuespetre

👍8

सबसे उपयोगी टिप्पणी

दोस्तों!

मैंने अभी-अभी पॉलिश की है और Decorate<TService> एपीआई को मेरे ऊपर दिए गए सार से स्क्रूटर (v1.9) में शामिल किया है।

इसका उपयोग कैसे करें इसका एक उदाहरण यहां दिया गया है (README.md से):

var collection = new ServiceCollection();

// First, add our service to the collection.
collection.AddSingleton<IDecoratedService, Decorated>();

// Then, decorate Decorated with the Decorator type.
collection.Decorate<IDecoratedService, Decorator>();

// Finally, decorate Decorator with the OtherDecorator type.
// As you can see, OtherDecorator requires a separate service, IService. We can get that from the provider argument.
collection.Decorate<IDecoratedService>((inner, provider) => new OtherDecorator(inner, provider.GetRequiredService<IService>()));

var serviceProvider = collection.BuildServiceProvider();

// When we resolve the IDecoratedService service, we'll get the following structure:
// OtherDecorator -> Decorator -> Decorated
var instance = serviceProvider.GetRequiredService<IDecoratedService>();

khellang 8 सित॰ 2016

👍7

सभी 31 टिप्पणियाँ

हम ऐसा कुछ समर्थन नहीं करने जा रहे हैं। समस्या यह है कि यह एक बहुत ही विशिष्ट विशेषता है और हमें इस तरह से काम करने के लिए अन्य DI सिस्टम की आवश्यकता होगी। या हम बस हार मान सकते हैं और आपको हमारा इस्तेमाल करने के लिए मजबूर कर सकते हैं

davidfowl 18 दिस॰ 2015

शोध के लिए क्या आप कुछ अन्य डीआई सिस्टम पर एक नज़र डाल सकते हैं और देख सकते हैं कि वे उन समस्याओं को कैसे हल करते हैं। अगर वे इसकी अनुमति भी देते हैं

davidfowl 18 दिस॰ 2015

NInject किसी अन्य विशेष कार्यान्वयन में इंजेक्शन लगाते समय किसी विशेष कार्यान्वयन के विनिर्देशन का उपयोग करने की अनुमति देता है। 'कारखाने' की स्थिति के बारे में निश्चित नहीं है।
स्ट्रक्चर मैप समान विनिर्देश की अनुमति देता है, साथ ही साथ एक प्रकार निर्दिष्ट करने की क्षमता जिसके साथ अन्य पंजीकृत कार्यान्वयन को पहले से लपेटना है।
स्प्रिंग.नेट मुझे यकीन नहीं है; मेरी प्रारंभिक खोज एक उदाहरण नहीं देती है।
ऐसा प्रतीत होता है कि विंडसर आपको प्रत्येक प्रकार को बस पंजीकृत करने की अनुमति देता है, हालांकि ऐसा लगता है कि यह एक विपरीत क्रम वाला दृष्टिकोण ले सकता है
Autofac NInject के समान एक दृष्टिकोण लेता है लेकिन ऐसा लगता है कि 'नाम' स्ट्रिंग कुंजियों का उपयोग करके अतिरिक्त विनिर्देश की आवश्यकता है
ऐसा प्रतीत होता है कि यूनिटी ने सजावट को संभालने के लिए नामांकित पंजीकरणों का उपयोग करते हुए ऑटोफैक के समान किया है, लेकिन एक डेकोरेटर एक्सटेंशन भी उपलब्ध है जो विंडसर के समान कार्य करता है।

ये सभी .NET के लिए 'प्रमुख' DI पुस्तकालय हैं जिन्हें मैं याद कर सकता हूँ। मैंने कुछ अन्य लोगों के नाम देखे जो लगभग उतने लोकप्रिय नहीं हैं और इसलिए मैंने उन पर अधिक ध्यान नहीं दिया।

मैंने जो प्रस्ताव रखा है वह विंडसर और यूनिटी के समान है।

tuespetre 18 दिस॰ 2015

👍1

@davidfowl :

मुझे पता है कि आपने कहा था कि आप दर्शन पर चर्चा करने के लिए यहां नहीं हैं, लेकिन एस्पनेट/निर्भरता इंजेक्शन कार्यान्वयन पहले से ही एक परिदृश्य के लिए रिकर्सन का पता लगाने और बाहर निकलने से असंगत रूप से इस मुद्दे पर पहुंचता है लेकिन दूसरे नहीं। उस विसंगति को कई तरीकों से संबोधित किया जा सकता है:

StackOverflowException होने से रोकने के लिए फ़ैक्टरी परिदृश्य में पहचान जोड़ें
कंस्ट्रक्टर परिदृश्य से पहचान निकालें और StackOverflowException होने दें
कंस्ट्रक्टर परिदृश्य से पहचान को हटा दें लेकिन StackOverflowException को कभी भी होने से रोकें, यह सुनिश्चित करके कि दी गई सेवा समाधान के लिए अनुपलब्ध है, जबकि यह पहले से ही हल करने की प्रक्रिया में है

इन तरीकों में से प्रत्येक विसंगति को हल करेगा, लेकिन केवल एक ही प्लेट में कुछ उपयोगी लाएगा।

उस मामले के अलावा, हमारे पास 'स्कोप' का मामला है, जो एक कार्यान्वयन विवरण है जिसकी गारंटी IServiceProvider इंटरफ़ेस द्वारा नहीं है। और जबकि अन्य DI पुस्तकालय जो एक-विधि IServiceProvider इंटरफ़ेस को लागू करते हैं, कुछ प्रकार के स्कोपिंग को लागू कर सकते हैं, कुछ शायद नहीं। कृपया मुझे सुधारें यदि मैं इसके बारे में गलत हूं, लेकिन इस पर विचार करते हुए, किसी भी प्रकार के 'विशेष' कार्यान्वयन विवरण होने का विरोध कहां से हो रहा है? यहां उन चीजों की पूरी सूची दी गई है जो एस्पनेट/निर्भरता इंजेक्शन के कार्यान्वयन द्वारा कार्यान्वित की जाती हैं जो IServiceProvider द्वारा उजागर किए गए अत्यंत गैर-वर्णनात्मक GetService(Type) इंटरफ़ेस से बाहर जाती हैं:

IServiceProvider को एक सेवा के रूप में स्वचालित रूप से पंजीकृत करना
IServiceScopeFactory . को लागू करना और स्वचालित रूप से पंजीकृत करना
खुले तौर पर जेनेरिक IEnumerable<> सेवा को लागू करना और स्वचालित रूप से पंजीकृत करना जिसका उपयोग एक निश्चित प्रकार द्वारा पंजीकृत प्रत्येक सेवा को पुनः प्राप्त करने के लिए किया जा सकता है

अब, विशेष रूप से उन अन्य कंटेनर पुस्तकालयों के बारे में फिर से, जैसे कि NInject, स्ट्रक्चर मैप, और ऑटोफैक, जिस तरह से वे डेकोरेटर्स के विनिर्देशन की अनुमति देते हैं, वह एस्पनेट/निर्भरता इंजेक्शन के कार्यान्वयन के लिए उपलब्ध फैक्ट्री लैम्ब्डा विधि के साथ बहुत आसानी से पूरा किया जाता है, यदि केवल वह कार्यान्वयन रिकर्सन को रोक देगा सामने। :आँख मारना:

ईमानदारी से, मैंने अन्य डीआई पुस्तकालयों की पेशकश के बारे में बहुत कुछ नहीं देखा है जो एस्पनेट/निर्भरता इंजेक्शन कार्यान्वयन के साथ संभव नहीं है। मुझे लगता है कि 'अन्य कंटेनरों को यह या वह करने देना' का पूरा मुद्दा वास्तव में एक गैर-मुद्दा है।

tuespetre 18 दिस॰ 2015

DI सिस्टम में डेकोरेटर पैटर्न करने की क्षमता होना काफी उपयोगी और मूल्यवान है।

brockallen 18 दिस॰ 2015

👍7

मुझे यह उस पीआर में काम कर रहा है। इससे कोई फर्क नहीं पड़ता कि आप सेवाओं को किस क्रम में पंजीकृत करते हैं। स्कोप/ऑर्डर/आदि के 36 संयोजनों के साथ एक परीक्षण केस है। मुझे बताओ कि तुम क्या सोचते हो।

संपादित करें: इसने परिपत्र निर्भरता परिदृश्य के परिणाम को भी बदल दिया। अब, एक परिपत्र निर्भरता अपवाद के बजाय, आपको 'प्रकार की सेवा को हल करने में विफल ...' या जो भी अपवाद मिलेगा, जो अपने आप में परिपत्र के विकासकर्ता को सूचित कर सकता है।

tuespetre 18 दिस॰ 2015

मुझे यह फीचर आइडिया पसंद है लेकिन इसे बैकलॉग में ले जाना क्योंकि हम इस समय नई सुविधाओं को बंद कर रहे हैं।

Eilon 29 दिस॰ 2015

सज्जाकारों के लिए समर्थन बहुत अच्छा होगा, यही एकमात्र बड़ी विशेषता है जो मुझे अभी याद आ रही है।

मुझे पता है, एक अलग कंटेनर का उपयोग करना आसान होगा, लेकिन मुझे यह तथ्य पसंद नहीं है कि आपके डीआई और तीसरे पक्ष के कंटेनर को अलग-अलग कॉन्फ़िगर किया जाना है। किसी एप्लिकेशन में कंटेनर कॉन्फ़िगरेशन के लिए दो अलग-अलग तरीकों का होना अजीब/भ्रमित करने वाला है।

cwe1ss 9 मई 2016

मुझे पता है, एक अलग कंटेनर का उपयोग करना आसान होगा, लेकिन मुझे यह तथ्य पसंद नहीं है कि आपके डीआई और तीसरे पक्ष के कंटेनर को अलग-अलग कॉन्फ़िगर किया जाना है। किसी एप्लिकेशन में कंटेनर कॉन्फ़िगरेशन के लिए दो अलग-अलग तरीकों का होना अजीब/भ्रमित करने वाला है।

आप केवल एक कंटेनर को कॉन्फ़िगर कर रहे हैं। आपका मतलब IServiceCollection (सेवा पंजीकरण का वर्णन करने के लिए मेटाडेटा का एक समूह) को विशिष्ट कंटेनर एपीआई में बदलना होगा। वह 2 कंटेनरों को कॉन्फ़िगर नहीं कर रहा है (और यह दूर नहीं जा रहा है)।

पुनश्च: हमसे इस कंटेनर में सुविधाओं को जोड़ने की अपेक्षा न करें क्योंकि आपको कुछ ऐसा करने के लिए किसी तृतीय पक्ष कंटेनर का उपयोग करने की आवश्यकता है जो समर्थित नहीं है। हम इस कंटेनर में बहुत ही विवेकपूर्ण तरीके से सुविधाओं को जोड़ेंगे।

davidfowl 9 मई 2016

आपके उत्तर के लिए धन्यवाद, डेविड! मुझे वास्तव में IServiceCollection अमूर्त पसंद है क्योंकि यह आसान है और यह मुझे इसे अपने पुस्तकालयों में भी उपयोग करने की अनुमति देता है। और मेरी मेजबान परियोजनाएं अभी भी एक अलग कंटेनर का उपयोग करने का निर्णय ले सकती हैं।

हालांकि मेरे पुस्तकालयों में से एक में मुझे सजावटी का उपयोग करने की आवश्यकता होगी। अब मैं थोड़ा फंस गया हूं ... मैं या तो अपने पुस्तकालयों में IServiceCollection का उपयोग नहीं करने का निर्णय ले सकता हूं या किसी तृतीय पक्ष कंटेनर का उपयोग कर सकता हूं और इसलिए मेरे पुस्तकालयों में एकाधिक कंटेनर हैं (जिन्हें तब कॉन्फ़िगर/कॉल किया जाना है अलग-अलग - या तो ConfigureServices के माध्यम से या किसी अन्य विधि के माध्यम से)

मुझे पता है, आदर्श रूप से मेरे पुस्तकालयों में कोई डीआई कोड नहीं होगा लेकिन प्रत्येक पुस्तकालय में एक डिफ़ॉल्ट कॉन्फ़िगरेशन होना वाकई अच्छा है (जैसे आप इसे हर जगह भी करते हैं)।

तो क्या आप हमारे अपने पुस्तकालयों में IServiceCollection का उपयोग न करने और इसके बजाय हर जगह एक तृतीय पक्ष कंटेनर का उपयोग करने की अनुशंसा करेंगे?

cwe1ss 9 मई 2016

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

khellang 9 मई 2016

👍2

मेरे मामले में मैं अपनी कंपनी के लिए आंतरिक पुस्तकालयों के बारे में बात कर रहा हूं। मुझे पता है कि ऐसा करना बेहतर होगा, लेकिन आप जानते हैं... समय सीमा :-)

और एक काउंटर तर्क जोड़ने के लिए - अगर हमें पुस्तकालयों में कंटेनरों का उपयोग नहीं करना चाहिए, तो यह जीथब परियोजना क्यों मौजूद है ??? :-)

cwe1ss 9 मई 2016

बीटीडब्लू: मेरा वास्तविक जीवन परिदृश्य एक बिजनेस कोड लाइब्रेरी है जिसमें कई कमांड हैंडलर शामिल हैं। मैं हैंडलर को कॉल करने के लिए MediatR के समान कुछ उपयोग कर रहा हूं। मैं सज्जाकार के रूप में सत्यापन, प्राधिकरण, ... जोड़ना चाहूंगा क्योंकि यह एक अत्यंत सरल समाधान है।

चूंकि IServiceCollection में कोई डेकोरेटर समर्थन नहीं है, मैं पहले से ही एक अलग IMessageInterceptor-इंटरफ़ेस का उपयोग कर रहा हूं और प्रेषक वास्तविक हैंडलर को कॉल करने से पहले और बाद में इसके सभी पंजीकृत उदाहरणों को कॉल करता है। यह ठीक है, लेकिन यह त्रुटि प्रबंधन, लेन-देन से निपटने आदि के लिए अजीब होने लगता है क्योंकि आप इसके ऊपर सिर्फ कोशिश नहीं कर सकते हैं।

मैं नए ASP.NET अनुरोध/मिडलवेयर पाइपलाइन के समान कुछ भी कर सकता था जो प्रतिनिधि आधारित है लेकिन यह मेरे लिए एक ओवरकिल की तरह लगता है।

शायद आपके पास कुछ और विचार हैं ?! मेरे लिए आपका फ़ीडबैक वाकई सराहनीय है!

cwe1ss 9 मई 2016

और एक काउंटर तर्क जोड़ने के लिए - अगर हमें पुस्तकालयों में कंटेनरों का उपयोग नहीं करना चाहिए, तो यह जीथब परियोजना क्यों मौजूद है ??? :-)

एह, यह _apps_ में कंटेनरों का उपयोग करने के लिए मौजूद है?

शायद आपके पास कुछ और विचार हैं ?! मेरे लिए आपका फ़ीडबैक वाकई सराहनीय है!

केवल सजावट को मैन्युअल रूप से तार-तार करने के बारे में क्या?

कुछ छद्म कोड:

public class ErrorHandlingMediator : IMediator
{
    public ErrorHandlingMediator(IErrorHandler errorHandler, IMediator inner) { }
}

public class ValidatingMediator : IMediator
{
    public ErrorHandlingMediator(IEnumerable<IValidator> validators, IMediator inner) { }
}

public class TransactionMediator : IMediator
{
    public ErrorHandlingMediator(ITransactionManager transactionManager, IMediator inner) { }
}

// Add IErrorHandler, IValidators and ITransactionManager to the service collection.

services.AddScoped<IMediator>(provider => {
    var singleFactory = new Func<Type, object>(provider.GetService);
    var multiFactory = new Func<Type, IEnumerable<object>>(provider.GetServices);

    // Let's configure the following pipeline: Error Handling -> Validation -> Transaction -> Request Handler

    return new ErrorHandlingMediator(
        provider.GetService<IErrorHandler>(),
        new ValidatingMediator(
            provider.GetServices<IValdiator>(),
            new TransactionMediator(
                provider.GetService<ITransactionManager>(),
                new Mediator( // This is the Mediator type from MediatR...
                    singleFactory,
                    multiFactory))));
});

यह निश्चित रूप से बिना किसी कंटेनर के भी पूरी तरह से किया जा सकता है, लेकिन आपको विभिन्न सेवाओं को हल करने के लिए हुक की आवश्यकता होगी, जैसे IErrorHandler आदि। मुस्कान:

khellang 9 मई 2016

👍2

o_O - मैं बेवकूफ हूँ, मैंने इसके बारे में नहीं सोचा। :-) यह गतिशील/सुंदर नहीं है लेकिन मुझे लगता है कि मैं निश्चित रूप से इसके साथ रह सकता हूं। धन्यवाद क्रिस्टियन !! अगर हम कभी किसी सम्मेलन में मिलते हैं तो एक बियर मुझ पर है। :बीयर:

सीखने के लिए बहुत कुछ है! :-)

cwe1ss 9 मई 2016

शायद अन्य लोगों के लिए दिलचस्प है, जो इस तरह से कुछ के साथ संघर्ष करते हैं: मैं मध्यस्थ के बजाय IRequestHandler<TMessage> इंटरफ़ेस को सजाने की कोशिश कर रहा था। इस तरह, मध्यस्थ को कक्षाओं की इस श्रृंखला को बनाना/समाधान करना होगा और मुझे यह कोड वहां पसंद नहीं आया होगा। लेकिन मुझे लगता है कि उस मामले में भी मैं हैंडलर निर्माण के लिए एक और हुक प्रदान करके इसे अलग तरीके से हल कर सकता था। धन्यवाद फिर से, क्रिस्टियन!

cwe1ss 9 मई 2016

हम एक ढांचा तैयार कर रहे हैं जो एमवीसी ढांचे का विस्तार करता है और इसके एक हिस्से के रूप में हम अतिरिक्त कार्यक्षमता के साथ एमवीसी द्वारा प्रदान की जाने वाली कुछ सेवाओं को सजाने में सक्षम होना चाहते हैं। एक ढांचे के रूप में हम उस एप्लिकेशन पर एक विशिष्ट कंटेनर नहीं लगाना चाहते हैं जो हमारे ढांचे का उपयोग करेगा, लेकिन हम यह भी नहीं जानते कि एप्लिकेशन ने पहले से कौन सी ठोस सेवा कॉन्फ़िगर की है।

मुझे लगता है कि किसी भी फ्रेमवर्क के लिए एक ही समस्या उत्पन्न होगी जो उसी प्रकार की जेनेरिक एक्स्टेंसिबिलिटी प्रदान करने की कोशिश कर रही है क्योंकि ASP.NET कोर सेवा कॉन्फ़िगरेशन के माध्यम से भी करता है। कार्यक्षमता का विस्तार करने के लिए आपको या तो कंटेनर को नियंत्रित करना होगा, यानी एप्लिकेशन बनना होगा, या यह अनुमान लगाना होगा कि आप किस ठोस सेवा का विस्तार करेंगे। वैकल्पिक रूप से आपको अपने ढांचे में कारखानों या प्रदाताओं जैसे विशिष्ट विस्तार बिंदुओं को उजागर करने के लिए वापस आना होगा। क्या यह उचित वर्णन है?

तो इस नजरिए से ऐसा लगता है कि यह प्रस्तावित फीचर काफी मददगार होगा।

hennys 10 मई 2016

मुझे नहीं लगता कि बहुत से लोगों को इसका एहसास है, या वे बस परवाह नहीं करते हैं, लेकिन आईओसी कंटेनर के इस न्यूनतम, "सबसे कम आम भाजक" कार्यान्वयन में सुविधाओं पर ढेर करके, आप मूल रूप से अन्य कंटेनरों को बाहर कर रहे हैं जो कर सकते हैं ' t या कार्यक्षमता के इस आवश्यक सेट का समर्थन नहीं करेगा।

khellang 10 मई 2016

मैं दूसरों के लिए नहीं बोल सकता, लेकिन मैं (कम से कम) कंफर्मिंग कंटेनर समस्या से अवगत हूं। लेकिन चूंकि ढांचे में एक को लागू करने का निर्णय लिया गया है, मुझे लगता है कि जितना संभव हो उतने कंटेनर कार्यान्वयन को शामिल करने और समर्थन करने की इच्छा के बीच हितों का टकराव होगा और फ्रेमवर्क डेवलपर्स की इच्छा कंटेनर के नियंत्रण में नहीं है। अधिक से अधिक सुविधाओं तक पहुंच।

व्यक्तिगत रूप से मैं यह सुझाव देने के लिए पर्याप्त अनुभवी नहीं मानता कि संतुलन कहाँ होना चाहिए, लेकिन मैं एक दृष्टिकोण जोड़ना चाहता था जिसे मैंने इस बातचीत में उठाया नहीं देखा था।

hennys 10 मई 2016

मुझे लगता है कि जितना संभव हो उतने कंटेनर कार्यान्वयन को शामिल करने और समर्थन करने की इच्छा और ढांचे के डेवलपर्स की इच्छा के बीच हितों का टकराव होगा जो कंटेनर के नियंत्रण में नहीं है ताकि अधिक से अधिक सुविधाओं तक पहुंच हो सके।

आप इन फ्रेमवर्क डेवलपर्स का उल्लेख करते हैं जो अधिक से अधिक सुविधाओं तक पहुंच चाहते हैं। ये ढांचे किसी अन्य कंटेनर का उपयोग क्यों नहीं कर सकते हैं जिसमें ये सुविधाएं _पहले से ही हैं? मैं नहीं देखता कि यह कंटेनर कैसे विशेष है और सभी प्रकार के पुस्तकालयों और ढांचे में उपयोग/उपयोग किया जाना चाहिए, जबकि अन्य कंटेनर नहीं कर सकते हैं?

इसके अलावा, जैसा कि मैंने ऊपर उल्लेख किया है; कई लोग आपके ढांचे/लाइब्रेरी के खराब फॉर्म के उपभोक्ताओं पर एक विशिष्ट कंटेनर को मजबूर करने पर विचार करेंगे।

व्यक्तिगत रूप से मैं खुद को इतना अनुभवी नहीं मानता कि यह सुझाव दे सकूं कि वह संतुलन कहाँ होना चाहिए

अगर मैंने टीम को सही ढंग से समझा है, तो मुझे लगता है कि संतुलन कुछ इस तरह है "जो कुछ भी ढांचे को खुद बनाने की जरूरत है। कुछ और उन्नत के लिए, हम BYOC की सलाह देते हैं"।

यदि Microsoft को इस कंटेनर के लिए सुविधाओं का ढेर लगाना था, तो वे प्रभावी रूप से हत्या कर देंगे, या कम से कम .NET स्थान में अन्य, मौजूदा कंटेनरों के लिए कमरे से बहुत सारी हवा को चूस लेंगे, जैसा कि उन्होंने पहले विभिन्न के साथ किया है अन्य सामुदायिक प्रयास। अब, इसकी अभी भी कोई गारंटी नहीं है कि ऐसा नहीं होगा, लेकिन कंटेनर के दायरे को सीमित करने से कम से कम उस प्रभाव को सीमित कर दिया जाएगा।

khellang 10 मई 2016

मुझे यकीन नहीं है कि यह कितना प्रदर्शनकारी है, लेकिन ऐसा लगता है कि यह अच्छी तरह से काम करता है; https://gist.github.com/khellang/c9d39444f713eab04c26dc09d5687196 :मुस्कुराओ:

khellang 10 मई 2016

👍3

ये ढांचे किसी अन्य कंटेनर का उपयोग क्यों नहीं कर सकते हैं जिसमें पहले से ही ये सुविधाएं हैं?

मुझे विश्वास है कि आपने स्वयं इसका उत्तर दिया है। एक ढांचे के रूप में हम उपभोग करने वाले एप्लिकेशन पर एक विशिष्ट कंटेनर को बाध्य नहीं करना चाहते हैं।

मैं नहीं देखता कि यह कंटेनर कैसे विशेष है और सभी प्रकार के पुस्तकालयों और ढांचे में उपयोग/उपयोग किया जाना चाहिए, जबकि अन्य कंटेनर नहीं कर सकते हैं?

मुझे लगता है कि यह एक अमूर्तता है जो पहले से ही .NET ढांचे में है। निश्चित रूप से, हम एक अनुरूप कंटेनर के अपने या कुछ अन्य मौजूदा अमूर्त को उजागर करना चुन सकते हैं, जिसके लिए हम उन सुविधाओं तक सीमित नहीं हैं जो Microsoft को उनके ढांचे में आवश्यक हैं, लेकिन इसका मतलब है कि हमें अतिरिक्त कंटेनर एडेप्टर की आवश्यकता है जो वास्तव में मदद नहीं करता है लंबे समय में कोई भी।
वैकल्पिक रूप से हम ServiceCollection को पूरी तरह से अनदेखा कर देते हैं और अपने स्वयं के विस्तार बिंदुओं को उजागर कर देते हैं, लेकिन यह संभावित रूप से हमारे उपभोक्ताओं को उनके द्वारा अपेक्षित .NET एक्सटेंशन बिंदुओं तक पहुंचने से रोक सकता है।

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

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

hennys 10 मई 2016

मुझे विश्वास है कि आपने स्वयं इसका उत्तर दिया है। एक ढांचे के रूप में हम उपभोग करने वाले एप्लिकेशन पर एक विशिष्ट कंटेनर को बाध्य नहीं करना चाहते हैं।

बिल्कुल। आप मेरे लिए बिंदु बना रहे हैं: पलक: माइक्रोसॉफ्ट क्यों है। एक्सटेंशन। निर्भरता इंजेक्शन "विशिष्ट कंटेनर" नहीं है?

मैंने यह भी कहा है कि यदि आप अपने ढांचे/पुस्तकालय में "एक विशिष्ट कंटेनर" पर निर्भर नहीं रहना चाहते हैं, तो आपको "आउटसोर्स" संरचना के लिए हुक लगाने की आवश्यकता है।

मुझे लगता है कि यह एक अमूर्तता है जो पहले से ही .NET ढांचे में है।

नहीं यह नहीं। यह एक NuGet पैकेज है जिस पर आप किसी भी अन्य IoC कंटेनर की तरह निर्भर हैं: मुस्कान:

निश्चित रूप से, हम एक अनुरूप कंटेनर के अपने या कुछ अन्य मौजूदा अमूर्त को उजागर करना चुन सकते हैं, जिसके लिए हम उन सुविधाओं तक सीमित नहीं हैं जो Microsoft को उनके ढांचे में आवश्यक हैं, लेकिन इसका मतलब है कि हमें अतिरिक्त कंटेनर एडेप्टर की आवश्यकता है जो वास्तव में मदद नहीं करता है लंबे समय में कोई भी।

या आप किसी भी "अनुरूप कंटेनर" का उपयोग न करने के लिए एक्स्टेंसिबिलिटी पॉइंट रख सकते हैं।

BTW, क्या आप जानते हैं कि MS.Ext.DI के लिए कई कंटेनरों में पहले से ही ये एडेप्टर हैं? उस पर मेरा ब्लॉग पोस्ट पढ़ें: पलक:

आप अपनी लाइब्रेरी में केवल IServiceProvider का उपयोग कर सकते हैं। वह इंटरफ़ेस .NET 1.1 के बाद से अच्छे पुराने बीसीएल ( System नेमस्पेस के तहत mscorlib) में रहा है। यदि आप वर्ग परिभाषा के बॉयलरप्लेट की गणना नहीं करते हैं और इंटरफ़ेस को स्वयं लागू करते हैं, तो कंटेनर के लिए इस इंटरफ़ेस को लागू करना वस्तुतः कोड की 4 पंक्तियाँ हैं।

वैकल्पिक रूप से हम ServiceCollection को पूरी तरह से अनदेखा कर देते हैं और अपने स्वयं के विस्तार बिंदुओं को उजागर कर देते हैं, लेकिन यह संभावित रूप से हमारे उपभोक्ताओं को उनके द्वारा अपेक्षित .NET एक्सटेंशन बिंदुओं तक पहुंचने से रोक सकता है।

ये .NET एक्सटेंशन पॉइंट क्या हैं जिनके बारे में आप बात कर रहे हैं?

हमें बस उस प्रभाव को मापना होगा जो प्रत्येक डेकोरेटर के लिए एक सेवा प्रदाता बनाने से होता है।

मुझे नहीं लगता कि आपको ऐसा करने की ज़रूरत है?

एक संभावित मुद्दा यह भी है कि सजाए गए कार्यान्वयन को गलत सेवा निर्भरता इंजेक्शन मिल सकती है यदि उन्हें बदले में सजावट के बाद बदल दिया जाता है।

आप इससे कभी कैसे दूर होंगे? संकेत: आप नहीं कर सकते, IServiceCollection परिवर्तनशील है :stuck_out_tongue_winking_eye:

मुझे यह भी लगता है कि माइक्रोसॉफ्ट मुख्य रूप से .NET ढांचे से और चीजों के अनुप्रयोग पक्ष से कंटेनर कार्यान्वयन को देख रहा है और ढांचे के डेवलपर्स की कुछ जरूरतों से चूक गया है।

माइक्रोसॉफ्ट ने पहले से ही IServiceProvider एब्स्ट्रैक्शन के शीर्ष पर एक सुंदर सभ्य ढांचा बनाया है, अर्थात् ASP.NET: मुस्कान: यह कंटेनर उस ढांचे की जरूरतों को पूरा करने के लिए एक नंगे-हड्डियों के कार्यान्वयन के लिए है, इससे ज्यादा कुछ नहीं, कुछ भी कम नहीं .

khellang 10 मई 2016

दोस्तों!

इसका उपयोग कैसे करें इसका एक उदाहरण यहां दिया गया है (README.md से):

var collection = new ServiceCollection();

// First, add our service to the collection.
collection.AddSingleton<IDecoratedService, Decorated>();

// Then, decorate Decorated with the Decorator type.
collection.Decorate<IDecoratedService, Decorator>();

// Finally, decorate Decorator with the OtherDecorator type.
// As you can see, OtherDecorator requires a separate service, IService. We can get that from the provider argument.
collection.Decorate<IDecoratedService>((inner, provider) => new OtherDecorator(inner, provider.GetRequiredService<IService>()));

var serviceProvider = collection.BuildServiceProvider();

// When we resolve the IDecoratedService service, we'll get the following structure:
// OtherDecorator -> Decorator -> Decorated
var instance = serviceProvider.GetRequiredService<IDecoratedService>();

khellang 8 सित॰ 2016

👍7

@खेलंग हाँ, यह वही है जो हमें IdentityServer में जोड़ना था ...

brockallen 8 सित॰ 2016

👍2

@खेलंग अपनी परियोजना प्रदान करने के लिए धन्यवाद, इससे मुझे मदद मिली।

यह अच्छा होगा यदि डेकोरेटर कार्यक्षमता को डिफ़ॉल्ट पेशकश में जोड़ा जाए।

MatthewLymer 3 मार्च 2017

👍1

@brockallen IdentityServer4 के आंतरिक कार्यान्वयन में सज्जाकारों का उपयोग कैसे किया गया?

infinnie 3 जुल॰ 2017

@brockallen IdentityServer4 के आंतरिक कार्यान्वयन में सज्जाकारों का उपयोग कैसे किया गया?

मुख्य रूप से उन सेवाओं के आसपास कैशिंग करना जो स्टोर से डेटा लोड करती हैं, लेकिन हमें उनकी कार्यक्षमता बढ़ाने के लिए कुछ अंतर्निहित प्रमाणीकरण सेवाओं को लपेटने के लिए भी ऐसा करने की आवश्यकता है।

brockallen 3 जुल॰ 2017

👍1

@davidfowl DI के साथ डेकोरेटर्स का उपयोग करना बहुत विशिष्ट विशेषता नहीं है (मेरे विरोध में); इसके विपरीत, यह ठोस सिद्धांतों में एक मौलिक पैटर्न है जो आसानी से एसआरपी सिद्धांत को सुविधाजनक बनाता है।

हालांकि, कंटेनर द्वारा प्रदान की गई फैक्ट्री लैम्डा विधि का उपयोग करके इसे प्राप्त करना काफी आसान (हालांकि उतना सुरुचिपूर्ण नहीं) है। इसके लिए सामान्य समर्थन देखना चाहेंगे।

var collection = new ServiceCollection() .AddSingleton<IPackageService>(p => new FaultHandlingPackageService(p.GetService<PackageService>()));

andersborum 12 जुल॰ 2017

@andersborum यह वही है जो मैं स्क्रूटर के साथ कर रहा हूं। कोड देखें। यह कुछ भी नहीं है।

khellang 12 जुल॰ 2017

इस मुद्दे को aspnet/Home#2350 . पर ले जाया गया था

aspnet-hello 1 जन॰ 2018

क्या यह पृष्ठ उपयोगी था?

0 / 5 - 0 रेटिंग्स

Dependencyinjection: पुनरावर्ती रिज़ॉल्यूशन को रोककर सेवाओं को एक-दूसरे को सजाने दें

उपयोगकर्ता कहानी / केस परिदृश्य का उपयोग करें

उदाहरण इंटरफ़ेस और कार्यान्वयन

सेवा संग्रह स्थापित करने के तरीकों के उदाहरण

कंस्ट्रक्टर रिज़ॉल्यूशन का उपयोग करना

कार्यान्वयन कारखानों का उपयोग करना

व्यवहार संबंधी विचार

सबसे उपयोगी टिप्पणी

सभी 31 टिप्पणियाँ

संबंधित मुद्दों