أفضل الممارسات لمكتبة .NET متعددة الهدف

Question

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

مكتبتي مبسطة للغاية في الأنواع التي تشير إليها ، ويبدو أن التبعية الحقيقية الوحيدة هي .NET 3.0 أو أعلى (لأنه يشير إلى Func<T> وما شابه ذلك).

أريد أن تكون مكتبتي قابلة للاستخدام من خلال أهداف متعددة ، بما في ذلك خادم .NET 4.0 ، وخادم .NET 3.5 ، و Windows Phone 7 Silverlight ، و Silverlight العادي ، و XNA (الهاتف) ، و XNA (Windows) ، و XNA (Xbox 360).

أتأكد من عدم استخدام أي أنواع غير متوفرة على المنصات التي أستهدفها ، على سبيل المثال HashSet<T> غير متوفر على Windows Phone 7 ، لذلك أنا لا أستخدمه.

هل سأحتاج إلى عمل مشاريع مختلفة ، وبالتالي DLL متعددة لكل من هذه الأهداف أم أن هناك طريقة ما لإنتاج DLL مشتركة لاستخدامها جميعًا؟

Answer 1

كان هناك حديث في PDC هذا العام حول القيام بهذا النوع من الأشياء:

هذا هو الفيديو و هذه هي الشرائح.

Answer 2

تفصل ملفات المشروع مع ملفات المصدر المشتركة المشتركة هي الطريق للذهاب. تأكد من ضبط المشاريع على مجلدات الإخراج المختلفة (على سبيل المثال لا \bin\Debug, ، لكن \CF\bin\debug) لمنع الإزعاج عند استهلاك المكتبة من أهداف متعددة (مثل سطح المكتب ومشروع الجهاز).

ال OpenNetcf.IOC الإطار هو مثال على ذلك - فهو يدعم سطح المكتب ، CF ، Windows Phone و Monotouch مع نفس ملفات المصدر ، ولكن فصل ملفات المشروع لكل منصة. كانت محاولة تجميع مجموعة ثنائية واحدة قابلة للاستخدام عليها جميعًا فوضويًا للغاية ويصعب الحفاظ عليها.

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

Answer 3

أفعل شيئًا مشابهًا مع مكتبة تستهدف .NET و Silverlight. لدي مجموعة واحدة من ملفات المصدر وفصل ملفات المشروع التي ترتبط بنفس الملفات المشتركة.

في بعض الأحيان ، أستخدم التجميع الشرطي لتضمين ميزات فقط لـ .NET وليس Silverlight ، أو للاستفادة من الميزات المتوفرة في .NET التي تؤدي إلى تنفيذ أجمل وتنفيذ التراجع عن Silverlight حيث تحتوي على فجوات.

يمكن استخدام نفس النهج للمنصات الأخرى التي تذكرها - مجموعة واحدة من ملفات المصدر ، ولكن ملف مشروع منفصل لكل هدف منصة.

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

Answer 4

انظر الى أدوات المكتبة المحمولة (آخر تحديث: 6/17/2011) ملحق من فريق BLC (Microsoft) وهذه المقدمة مقال MSDN (آخر تحديث: أغسطس 2011).

Answer 5

أود أن أقترح مكتبة لكل من النظام الأساسي. دعني أوضح.

دعنا نقول الكامل .NET Framework يتضمن مجموعة من الميزات ، والطرق التي ليست جزءًا من .NET Compact Framework كما الشخص الذي قد تجده مع Windows CE والهواتف الذكية. لذلك ، من أجل الاستفادة الكاملة من الحمل الكامل لإمكانيات كل منصة ، أود الاستفادة من مكتبة مشتركة الكثير من الواجهات ، ثم تقوم بتنفيذ تلك الواجهات داخل أ .NET Framework platform specific مكتبة الفصل التي ستتيح لك الاستفادة الكاملة من ما يتم تقديمه على منصة معينة.

من ناحية أخرى ، إذا كان إعادة استخدام الشفرة الشائعة ، ومن أجل الصيانة ، قد تفضل الذهاب مع مكتبة واحدة "Do-Them-Col". بموجب مثل هذه المتطلبات ، ستحتاج إلى أن تكون على دراية تامة بكل الاختلافات بين العديد من المنصات التي ترغب في دعمها.

من الواضح أن هذا سؤال مهم للعمارة والهندسة المعمارية ، اعتبارًا من كلاهما سيعاني من نقص منصة واحدة على الآخر.

إليكم كيف يمكنني المضي قدمًا أمام مثل هذا الموقف:

1. أود أن أتحقق من الاختلافات بين إطار عمل المنصة المحدد .NET ؛
2. أود أن أضع جانبا كل (حسب الحاجة) الكائنات المشتركة التي تعتقد أنك قد تحتاجها ؛
3. أود تسليط الضوء على الاختلافات ، أي الكائنات التي يمكنك استخدامها تحت نظام أساسي واحد ، ولكن ليس الآخر ؛

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

وهذا هو ، لنوع من نهج الشلال.

---

أما بالنسبة لنهج Scrum ، إذا جاز لي أن أقول أن هذا يشير إلى التجريبية ، أود أن أقول جرب مكتبة مشتركة واحدة لهم جميعًا ، ومعرفة ما يمكنك القيام به. إذا صادفت بعض الأشياء التي لا يمكنك فعلها تمامًا ، فقد يكون من المناسب إنشاء مكتبة فئة أخرى فقط تعتمد على مكتبة "Do-them-Coll" بحيث يكون لديك كتلة مشتركة لكل منصة ، ثم بعضها محدد مكتبات لما لا يمكنك فعله في المشترك. افعل ذلك ، وانظر إلى المزايا التي حصلت عليها منها ، وابحث عن طريقة للخروج من المتاعب عندما يكون الوقت أكثر تحديداً.