شيء يجب مراعاته عند تنفيذ ذلك هو استخدام مشروع Microsoft.Extensions.DependencyInjection.Abstractions باعتباره التبعية الرئيسية عبر التنفيذ في ماوي. من خلال تقليل المساحة التي تبلغ Microsoft.Extensions.DependencyInjection لاستخدامها فقط في إنشاء الحاوية ، ستمكّن مكتبات وأطر عمل الجهات الخارجية من أن تكون محايدة للحاوية.

يتيح ذلك للمطور أو إطار العمل خيار استخدام حاوية مختلفة عن تلك التي توفرها Maui. باستخدام مشروع التجريد ، فإن العمل المطلوب من قبل المطور أو إطار العمل هو مجرد تنفيذ الواجهات في مشروع التجريد. حيث ستستخدم جميع رموز Maui الواجهات فقط. سيوفر هذا نقطة تمديد هائلة للجميع حيث نعيد العمل على كيفية عمل Dependency Injection في النظام الأساسي.

ahoefling نعم هكذا سوف تستهلك ماوي كل شيء. السؤال الوحيد هو ما إذا كنا بحاجة إلى استخدام الحاوية التي تم تنفيذها بالفعل من أجل التنفيذ الافتراضي أو طرح منطقتنا التي تتسم بقدر أكبر من التنقل فيما يتعلق بالأداء

PureWeen تنفيذ الحاوية الافتراضية الحالي يعمل جيدًا للجوال. ومع ذلك ، فإن مجموعة التبعيات التي يجلبها صانع المضيف مذهلة.

@ PureWeen هذا شيء عظيم أن نسمع!

بقدر ما أفهم أن أداء حاوية مشروع الامتدادات قوي جدًا. أوصي بأن نبدأ بالحاوية الافتراضية ويمكننا التكرار إذا كانت اختبارات الأداء لا تلبي توقعاتنا. لقد جمعت نموذجًا صغيرًا من التعليمات البرمجية لما كنت أفكر فيه للتعامل مع بعض نقاط الامتداد.

يتيح لنا ذلك تبديل الحاوية بسهولة بواسطة المطورين أو الأطر أو منصة Maui إذا أردنا استخدام حاوية مختلفة.

ربما يبدو System.Maui.Application شيئًا كالتالي:
ج #
تطبيق فئة عامة: Element و IResourcesProvider و IApplicationController و IElementConfiguration
{
حاوية IServiceProvider العامة {get؛ }

protected virtual IServiceProvider CreateContainer()
{
    var serviceCollection = new ServiceCollection();
    RegisterDependencies(serviceCollection);
    return serviceCollection.BuildServiceProvider();
}

// This should be implemented in the app code
protected virtual void RegisterDependencies(IServiceCollection serviceCollection)
{
    // TODO - Register dependencies in app code
}

public Application()
{
    Container = CreateContainer();

    // omited code
}

// omitted code

}
""

ahoefling هل يمكننا استخدام هذا للسماح للأشخاص بإنشاء IServiceProvider الخاصة بهم؟

https://docs.microsoft.com/en-us/dotnet/api/microsoft.extensions.hosting.hostbuilder.useserviceproviderfactory؟view=dotnet-plat-ext-3.1

هذا ما تعلق به أشياء مثل AutoFac

بقدر ما أفهم ، يوفر Host Builder واجهة برمجة تطبيقات غنية لإضافة المزيد من التبعيات الافتراضية مثل تسجيل الخروج من الصندوق. حيث الكود الذي اقترحه هو أكثر هزيلة. لا أعتقد أن أيًا من الطريقتين "صحيح" أكثر من الآخر ، حيث أنهما يحلان مشكلات مختلفة باستخدام حقن التبعية.

منشئ المضيف
إذا أردنا إنشاء الآراء التي سيحدث فيها تسجيل وحدة التحكم بطريقة معينة ودعنا نقول أن HttpClientFactory سيعمل بطريقة معينة أكثر من أن يكون Host Builder هو الخيار الأفضل لدينا على الأرجح.

مجموعة خدمة العجاف
إذا أردنا أن يكون نظام DI الخاص بنا ضعيفًا قدر الإمكان والسماح لمطور التطبيق بتحديد ما الذي سيعمل معه وما لا يعمل ، فأعتقد أن الكود الذي اقترحه أو ما شابه ذلك سيكون طريقة لتنفيذه.

الطريقة التي أنظر بها إلى المشكلة هي الطريقة الأقل توغلًا لمبادلة DependencyService . إذا كان الهدف النهائي هو اتباع الأنماط الموجودة مع asp.net الأساسية ونموذج باني المضيف ، فمن الأفضل على الأرجح إنشاء فئة Startup.cs التي تستخدم منشئ المضيف.

الكود في OP يمثل مشكلة لأنه غير واضح من الأنواع التي تتضمن كيفية عمل ServiceProvider.GetService<MainPage>() ، وكيف يتم اكتشاف MainViewModel . كما يتضمن أيضًا null والذي يجب أن يطلق تحذيرًا ببدائل النيكوتين. كل هذا يبدو وكأنه وسيلة للتحايل على نظام الكتابة. ASP.Net ليس مثالاً ساطعًا لواجهة برمجة تطبيقات نظيفة.

من المهم أن يكون المستخدمون قادرين على تجنب استخدام هذه الإمكانية ، كما يمكنهم الآن ، وتحديد الكائنات بطريقة آمنة من النوع. ومن خلال تجنبه ، يتجنب المستخدمون أيضًا دفع غرامة الأداء.

type App() =
    inherit Application()
    let vm = someMainViewModel(...)
    let mainPage = MainPage(vm)
    do  base.MainPage <- mainPage

إذا كان الأشخاص يرغبون في الحصول على نموذج عرض بطريقة قائمة على التفكير / الاتفاقية / التعليق التوضيحي ، فهل تحتاج MAUI حقًا إلى تقديم دعم صريح؟ لا يمكنهم فعل هذا على أي حال؟ الرابط الأصلي يشير إلى أنهم يستطيعون.

تضمين التغريدة

Host Builder مقابل Lean ServiceCollection

حسنًا ، معرفة فائدة أحدهما مقابل الآخر هو بالتأكيد جزء كبير من هذا!

في البداية كنت أتطلع فقط إلى مجموعات الخدمات الخالية من الهدر ، لكنني قررت المشاركة فيها.
جزء من ميزة استخدام اتجاه البناء هو أنه يرتبط فقط بتطبيقات netcore الحالية. على سبيل المثال ، باستخدام AutoFac ، يمكنك فقط استخدام نفس بنية حلقة بدء التشغيل بدلاً من الاضطرار إلى ابتكار شيء خاص بنا. معرفة المجال قابلة للتحويل.

PureWeen @ هذا أمر منطقي وفكرة جيدة لمواكبة توحيد .NET 5+ والمهارات القابلة للنقل بين الأدوات المختلفة.

أعتقد أنه يجب علينا إنشاء Startup.cs يقع بجوار App.cs أو App.xaml.cs الذي يعالج كل كود بدء التشغيل. سيؤدي هذا إلى توحيد قصة حقن التبعية في ماوي مع مشاريع أخرى في .NET Ecosystem. عندما قمت بتطبيق Dependency Injection في DNN Modules العام الماضي ، فعلت شيئًا مشابهًا سمح للمطورين بنقل مهاراتهم بسهولة تامة.

أعتقد أنه يجب علينا إنشاء Startup.cs يقع بجوار App.cs أو App.xaml.cs الذي يعالج جميع تعليمات بدء التشغيل.

لن يرغب المستخدمون الجدد في اكتشاف كل هذه الأشياء التمهيدية. في رأيي ، هذا هو آخر شيء تريده خاصة وأن MAUI سيخفف من جميع القواعد المعيارية حول AppDelegate و MainActivity وما إلى ذلك. 1 startup / app.xaml للتحكم فيها جميعًا.

وافق aritchie

أرغب في تمكين الأشخاص قدر الإمكان ولكن بالنسبة للمستخدمين الجدد ، يمكن أن يظل معظم هذا مخفيًا.
ولكن بمجرد أن يشعروا بالراحة يمكنهم البدء في توسيع الأمور.

أعتقد أن هناك سيناريوهات هنا حيث يمكن للمستخدمين الحصول على مزايا هنا دون الحاجة إلى شراء كل شيء.

على سبيل المثال مع شل يمكننا تقديم صيغة RegisterRoute مثل

Shell.RegisterRoute<TBindingContext, TPage>(String routeName);
أو فقط
Shell.RegisterRoute<TType>();

يستخدم ذلك تحت الغطاء كل هذه الأشياء لإنشاء الأنواع. ثم إذا أراد المستخدمون HttpContext التي سيتم حقنها في الخ ..

الجزء الآخر من هذا الاقتراح هو محاولة إنشاء جميع قوالب البيانات عبر IServiceProvider أيضًا مما يتيح بعض السيناريوهات الممتعة.

كنت ألعب مع بعض الاختلافات مع شل هنا بناءً على عينة جيمس

https://github.com/PureWeen/AllExtensions-DI-IoC/tree/shell_ioc

تضمين التغريدة

إذا كان الأشخاص يرغبون في الحصول على نموذج عرض بطريقة قائمة على التفكير / الاتفاقية / التعليق التوضيحي ، فهل تحتاج MAUI حقًا إلى تقديم دعم صريح؟

لا تقدم الخطة حاليًا أي شيء من خلال التفكير بسبب اعتبارات الأداء. قد تكون هناك بعض المجالات التي يمكننا تبسيط التسجيل دون القيام بها ولكن ما زلنا بحاجة إلى استكشاف هذه بعضها.

لقد قمت أيضًا بتحديث التعليق الأصلي باستخدام بناء جملة التسجيل

تضمين التغريدة

أوصي بوجود نوع من امتدادات المسارات من IServiceCollection بحيث يمكن لأشياء مثل Prism إضافة إلى النموذج. أستخدم XF منذ سنوات ولا أستخدم شل.

بمعنى آخر. الخدمات(اسم اختياري)

من ناحية أخرى ، يتمتع Shiny بكميات كبيرة من الاستخدام حول آليات Microsoft DI إذا كنت بحاجة إلى أفكار أخرى. انتهى بي الأمر برفض نموذج Hostbuilder (في شكله الحالي) بسبب كمية الأشياء التي جلبها والتي أدت إلى معركة مروعة مع الرابط. سأكون سعيدًا لمشاركة هذه التجارب في مكالمة في وقت ما.

ربما يمكن استخدام مولدات المصدر للتخفيف من مشاكل الأداء؟ ثم لا يزال بإمكانك استخدام السمات المخصصة ولكن يمكنك إجراء كل التسجيل (الافتراضي) في ملف مصدر تم إنشاؤه.

aritchie تبدو جيدة!

بمجرد أن نكون على الجانب الآخر من بناء المرح ، دعنا ندردش!

تضمين التغريدة

ربما مصدر مولدات

نعم!! نحن نرغب في إعادة هيكلة تسجيل العارض الحالي قبل Maui ونبحث في مولدات المصدر لهذا العمل. إذا انتهى بنا الأمر إلى السير في هذا الطريق ، فيمكننا بالتأكيد الاستفادة من ذلك

سيكون من الرائع أن يكون لديك DI في نماذج Xamarin ، لكنني لا أقرأ أي شيء عن نطاقات DI. يعد استخدام نطاقات DI طريقة رائعة لإدارة عمر المكونات. إنها مفيدة بشكل خاص عند العمل مع سياقات قاعدة بيانات EF core.

سيكون من الرائع أن يكون لديك تطبيق DI- على علم بـ ICommand الذي ينشئ نطاقًا ويطلب كائن معالج أوامر في هذا النطاق.

يعد استخدام حقن التبعية في تطبيقات WPF أمرًا صعبًا أيضًا ، لذلك ربما تتعاون مع فريق WPF للسماح باستخدام DI في WPF بطريقة مماثلة.

السؤال الوحيد هو ما إذا كنا بحاجة إلى استخدام الحاوية التي تم تنفيذها بالفعل من أجل التنفيذ الافتراضي أو طرح منطقتنا التي تتسم بقدر أكبر من التنقل فيما يتعلق بالأداء

أود أن أقول لتنفيذ حاوية لماوي من الصفر. كما ترى هنا ، DependecyService المطبق في Xamarin.Forms هو الأسرع. (أعلم ... هذه المقالة قديمة بعض الشيء ، لكنني لا أعتقد أن القيم تتغير كثيرًا).
كما أنه من الأفضل - من حيث الأداء - إنشاء حاوية DI الخاصة بنا. لكن مخاوفي تتعلق بعالم خالٍ من .NET 5. باستخدام .NET 5 ومولد الكود المصدري ، قد يكون لدينا حل آخر لهذه المشكلة.
وبالنسبة للجوال ، إذا كنت بحاجة إلى DI ثقيلًا ، فأنت تفعل شيئًا خاطئًا.

لقد جئت إلى هذا المستودع لاقتراح جعل تطبيقات MAUI تدعم المضيف العام (Microsoft.Extensions.Hosting) ، المفضل افتراضيًا (على الرغم من أن بعض الأشخاص قد يرغبون في الحماية) ، لأنه من الطبيعي جدًا أن يكون لديك DI في تطبيق واجهة المستخدم. قد يعني ذلك أن الناس بحاجة إلى فهم أقل ، إذا اعتادوا على حقن التبعية لـ asp.net الأساسية مما سيعمل أيضًا مع MAUI. بالنسبة للمبتدئين ، قد يكون من الجيد الحفاظ على التهيئة في أضيق الحدود.

بدلاً من أن أكون الأول ، وجدت هذه المشكلة ، وأعتقد أنها مناقشة جيدة!

لا يزال وجود تطبيقات تقدم بعض الخدمات وواجهة مستخدم صغيرة (الحالة والتكوين وما إلى ذلك) أمرًا شائعًا. في كل مرة أقوم فيها بإنشاء تطبيق صغير يوفر بعض الخدمات ، أجد الحاجة إلى تمديد ذلك باستخدام واجهة مستخدم.

لقد قمت بالفعل ببناء شيء ما لجعل تطبيقات Windows Forms و WPF تعمل على المضيف العام ، كما يتضح من هذا المشروع: https://github.com/dapplo/Dapplo.Microsoft.Extensions.
كنت آمل في استخدام هذا مع Greenshot ، لكنني لم أفرج عنه حاليًا بعد.
يوجد في العينات مشاريع WPF التي تستخدم ReactiveUI و MahApps و Caliburn.Micro.

من فضلك لا تجعلني أسجل المشاهدات يدويًا في DI. خذ الأفضل من بليزر ، إنه رائع! في Blazor يمكنني بسهولة تمرير المعلمات أو حقن الخدمة في المكون. لا حاجة لتسجيل المكون نفسه. أنا بحاجة فقط لتسجيل الخدمات. يعد MVVM أمرًا رائعًا للصفحات ، لكنني لم أشعر أبدًا بمزيد من الإنتاجية في إنشاء عروض المكونات المستضافة ذاتيًا. أكره بدء مشروع Xamarin و WPF و UWP جديد بسبب الأشياء غير الموجودة خارج الصندوق. مرة أخرى ، انظر إلى Blazor ، فهو مخطط حقيقي لجميع أطر عمل واجهة المستخدم الرسومية المستقبلية.

لا أستطيع أن أفهم سبب قيام أي شخص بإنشاء هاتين العبارتين المتتاليتين:

    services.AddTransient<IMainViewModel, MainViewModel>();
    services.AddTransient<MainPage>();

ما الخطأ في حقن الخدمة في كود المشاهدات خلفها؟ هذا ما تريده 99.99٪ من الوقت.

كما أنني أحب بشدة حقنة الخاصية في Blazor بدلاً من حقن المُنشئ ، لمجرد أنه أسهل.

لقد أطلقت للتو مكتبة تقوم بذلك لـ Xamarin.Forms https://github.com/hostly-org/hostly . يستخدم تطبيقًا مخصصًا لـ IHost ، والذي يمكن إعداده بسهولة في نقاط الدخول الأصلية. على سبيل المثال في MainActivity يمكنك استبدال:

LoadApplication(new App());`

مع:

new XamarinHostBuilder().UseApplication<App>()
   .UseStartup<Startup>()
   .UsePlatform(this)
   .Start();

كما أن لديها بعض الميزات الإضافية المضمنة مثل دعم تسجيل البرامج الوسيطة مع التنقل.

أنا أؤيد استخدام نظام DI الموجود خارج مساحة الاسم System.Maui بحيث يمكن مشاركة هذا الرمز مع كل من مشاريع MAUI وغير MAUI.

عندما أكون أقل ثقة فيما يتعلق باستخدام Microsoft.Extensions.DependencyInjection أو أي شيء يعتمد عليه مثل نظام DI هذا. لن أتظاهر بأنني خبير في هذا - بالتأكيد لم أستخدم العديد من أنظمة DI الحديثة. ومع ذلك ، أتساءل عما إذا كان الآخرون قد قرأوا الإصدار الثاني من "حقن التبعية. المبادئ والممارسات والأنماط "بقلم ستيفن فان دورسين ومارك سيمان. يخصصون قسمًا في الإصدار الثاني للنظر في Autofac و Simple Injector و Microsoft.Extensions.DependencyInjection ، وتقديم الإيجابيات والسلبيات ، بالإضافة إلى آرائهم / استنتاجاتهم. بينما يمكنني رؤية بعض فوائد استخدام Microsoft.Extensions.DependencyInjection (بشكل أساسي أنه يُستخدم في سيناريوهات Microsoft الأخرى) في عالم MAUI ، أتساءل عما إذا كان أي شخص هنا لديه خبرة في أنظمة DI المتعددة يمكنه التعليق على استنتاجات المؤلفين وإلى أي درجة هل تتعلق بعالم MAUI لاستخدام الأجهزة المحمولة وسطح المكتب؟