إلى أين يتم إدارة إطار عمل القابلية للتوسعة لـ .NET؟

Question

هل عمل أي شخص كثيرًا مع إطار عمل القابلية للتوسعة المُدار من Microsoft (MEF)؟يبدو نوعًا ما وكأنه يحاول تقديم كل شيء لجميع الأشخاص - إنه مدير الوظائف الإضافية!إنها كتابة البط!وأتساءل عما إذا كان أي شخص لديه تجربة معها، إيجابية أو سلبية.

نحن نخطط حاليًا لاستخدام تطبيق IoC عام مثل MvcContrib لمشروعنا الكبير التالي.هل يجب علينا رمي MEF في هذا المزيج؟

Answer 1

نحن لا نهدف إلى أن يكون MEF بمثابة IoC متعدد الأغراض.أفضل طريقة للتفكير في جوانب IoC لـ MEF هي تفاصيل التنفيذ.نحن نستخدم IoC كنموذج لأنها طريقة رائعة لمعالجة المشكلات التي نتطلع إلى حلها.

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

تخيل أنك عندما تريد توسيع نظامنا الأساسي في المستقبل، قمت بإسقاط ملف dll في مجلد bin، وبذلك تكون قد انتهيت.يضيء التطبيق الممكّن لـ MEF بالامتداد الجديد.هذه هي رؤية MEF.

Answer 2

يشير هذا المنشور إلى Managed Extensibility Framework Preview 2.

لذلك، قمت بإجراء جولة عبر MEF وكتبت عبارة "Hello World" سريعة، والتي يتم عرضها أدناه.يجب أن أقول أنه كان من السهل تمامًا الغوص فيه وفهمه.يعد نظام الكتالوج رائعًا ويجعل توسيع MEF نفسه أمرًا مباشرًا للغاية.من السهل توجيهه إلى دليل تجميعات الوظيفة الإضافية والسماح له بالتعامل مع الباقي.من المؤكد أن تراث MEF على غرار Prism يظهر بوضوح، لكنني أعتقد أنه سيكون من الغريب إذا لم يحدث ذلك، نظرًا لأن كلا الإطارين يتعلقان بالتكوين.

أعتقد أن أكثر ما يلفت انتباهي هو "سحر" _container.Compose().إذا نظرت إلى فئة HelloMEF، فسترى أن حقل الترحيب لم تتم تهيئته مطلقًا بواسطة أي من التعليمات البرمجية، الأمر الذي يبدو مضحكًا.أعتقد أنني أفضل الطريقة التي تعمل بها حاويات IoC، حيث تطلب صراحةً من الحاوية إنشاء كائن لك.أتساءل عما إذا كان هناك نوع من المُهيئ العام "لا شيء" أو "فارغ" قد يكون مناسبًا.أي.

private IGreetings greetings = CompositionServices.Empty<IGreetings>();

هذا على الأقل يملأ الكائن بـ "شيء ما" حتى يتم تشغيل كود تكوين الحاوية لملئه بـ "شيء" حقيقي.لا أعرف - إنه يشبه قليلاً الكلمات الأساسية الفارغة أو لا شيء في Visual Basic، والتي لم تعجبني دائمًا.إذا كان لدى أي شخص آخر بعض الأفكار حول هذا الأمر، أود أن أسمعها.ربما هو شيء أحتاج فقط لتجاوزه.تم تمييزه بسمة كبيرة الحجم [استيراد]، لذا فهو ليس لغزًا كاملاً أو أي شيء من هذا القبيل.

التحكم في عمر الكائن ليس أمرًا واضحًا، ولكن كل شيء يكون فرديًا بشكل افتراضي ما لم تقم بإضافة سمة [CompositionOptions] إلى الفئة المصدرة.يتيح لك ذلك تحديد Factory أو Singleton.سيكون من الجميل أن نرى المجمعة تضاف إلى هذه القائمة في وقت ما.

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

أعتقد أنه سيكون من الجيد نسخ ملفات DLL التي تم تحميلها بواسطة DirectoryPartCatalog.يتم الآن تأمين ملفات DLL بمجرد حصول MEF عليها.سيسمح لك هذا أيضًا بإضافة مراقب الدليل والتقاط الوظائف الإضافية المحدثة.هذا سيكون جميلا جدا...

أخيرًا، أشعر بالقلق بشأن مدى ثقة مكتبات DLL الإضافية وكيف ستتصرف MEF في بيئة ثقة جزئية أو إذا كانت كذلك.أظن أن التطبيقات التي تستخدم MEF ستتطلب الثقة الكاملة.قد يكون من الحكمة أيضًا تحميل الوظائف الإضافية في AppDomain الخاص بها.أعلم أنه يشبه إلى حد ما System.AddIn، ولكنه سيسمح بفصل واضح جدًا بين الوظائف الإضافية للمستخدم والوظائف الإضافية للنظام.

حسنا - ما يكفي من الثرثرة.إليك Hello World في MEF وC#.يتمتع!

using System;
using System.ComponentModel.Composition;
using System.Reflection;

namespace HelloMEF
{
    public interface IGreetings
    {
        void Hello();
    }

    [Export(typeof(IGreetings))]
    public class Greetings : IGreetings
    {
        public void Hello()
        {
            Console.WriteLine("Hello world!");
        }
    }

    class HelloMEF : IDisposable
    {
        private readonly CompositionContainer _container;

        [Import(typeof(IGreetings))]
        private IGreetings greetings = null;

        public HelloMEF()
        {
            var catalog = new AggregateCatalog();
            catalog.Catalogs.Add(new AssemblyCatalog(Assembly.GetExecutingAssembly()));
            _container = new CompositionContainer(catalog);
            var batch = new CompositionBatch();
            batch.AddPart(this);
            container.Compose(batch);

        }

        public void Run()
        {
            greetings.Hello();
        }

        public void Dispose()
        {
            _container.Dispose();
        }

        static void Main()
        {
            using (var helloMef = new HelloMEF())
                helloMef.Run();
        }
    }
}

Answer 3

فيما يتعلق بسؤال آندي حول الأمان للملحقات التي يقوم MEF بتحميلها (عذرًا، ليس لدي ما يكفي من النقاط بعد :))، مكان معالجة هذا الأمر موجود في الكتالوج.كتالوجات MEF قابلة للتوصيل بشكل كامل، لذا يمكنك كتابة كتالوج مخصص يتحقق من صحة مفاتيح التجميع، وما إلى ذلك قبل التحميل.يمكنك حتى استخدام CAS إذا كنت ترغب في ذلك.نحن نتطلع إلى إمكانية توفير خطافات للسماح لك بالقيام بذلك دون الحاجة إلى كتابة كتالوج.ومع ذلك، فإن مصدر الكتالوجات الحالية متاح مجانًا.أظن أن الحد الأدنى هو أن شخصًا ما (ربما في فريقنا) سوف ينفذ واحدًا ويطرحه في مشروع ملحق/مساهمة على CodePlex.

Answer 4

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

Answer 5

آندي، أعتقد أن جلين بلوك يجيب على العديد من الأسئلة (الطبيعية) مثل هذه الموجودة في هذا الموضوع في منتدى MSDN MEF:

مقارنة حاوية التركيب بحاويات IoC التقليدية .

إلى حد ما، إجابة Artem أعلاه صحيحة بالنسبة إلى الهدف الأساسي وراء MEF، وهو القابلية للتوسعة وليس التكوين.إذا كنت مهتمًا في المقام الأول بالتركيب، فاستخدم أحد العناصر الأخرى المشتبه بها المعتادة في IoC.من ناحية أخرى، إذا كنت مهتمًا في المقام الأول بقابلية التوسعة، فإن تقديم الكتالوجات والأجزاء ووضع علامات على البيانات الوصفية وكتابة البطة والتحميل المتأخر كلها أمور توفر بعض الاحتمالات المثيرة للاهتمام.وتسديدة قوية من كرزيستوف كوالينا هنا في شرح كيفية ارتباط MEF وSystem.Addins ببعضهما البعض.

Answer 6

لدى Ayende أيضًا كتابة جيدة جدًا هنا: http://ayende.com/Blog/archive/2008/09/25/the-managed-extensibility-framework.aspx

Answer 7

إنها ليست حقنة من حاوية التحكم.إنه إطار دعم المكونات الإضافية.

Answer 8

أود أن أقول أنه نظرًا لأنه سيتم تعليقه من مساحة الاسم "النظام" في .NET 4.0 Framework، فلا يمكنك أن تخطئ كثيرًا.سيكون من المثير للاهتمام أن نرى كيف يتطور MEF وما هو تأثير هاميلتون فيريسيمو (القلعة) على اتجاه MEF.

إذا كانت تصرخ مثل البطة، فقد تكون جزءًا من القطيع الحالي من حاويات IoC...

Answer 9

مناقشة أكثر تفصيلا حول هذا في هذا المنصب والتعليقات

http://mikehadlow.blogspot.com/2008/09/managed-extensibility-framework-why.html