المجلدات أو المشاريع في حل Visual Studio؟[مغلق]

Question

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

Answer 1

بشكل افتراضي، دائمًا ما عليك سوى إنشاء مجلد جديد ضمن نفس المشروع

• سوف تحصل على تجميع فردي (بدون الجمباز ILMerge الإضافي)
• من الأسهل التعتيم (لأنه سيكون لديك أنواع وأساليب عامة أقل، ومن الأفضل عدم وجودها على الإطلاق)

إن فصل كود المصدر الخاص بك إلى مشاريع متعددة يكون منطقيًا فقط إذا...

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

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

Answer 2

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

أفضّل الفصل إلى مجلدات (باستخدام مساحات الأسماء المناسبة) وإعادة البناء لفصل المشاريع عندما يكون لديك حالة إعادة استخدام واقعية.

Answer 3

كتب ديني:

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

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

هنا في SO، حاولنا أن نكون بسيطين للغاية من خلال ثلاثة مشاريع:

• مشروع MVC Web (الذي يقوم بعمل جيد في فصل طبقاتك إلى مجلدات افتراضيًا)
• مشروع قاعدة بيانات للتحكم في مصدر قاعدة البيانات لدينا
• اختبارات الوحدة ضد نماذج/وحدات التحكم MVC

لا أستطيع التحدث نيابةً عن الجميع، ولكنني سعيد بمدى بساطة الأمر - فهو يسرع عملية البناء حقًا!

Answer 4

عادةً ما أقوم بمشروع لواجهة المستخدم الرسومية ومشروع لمنطق الأعمال ومشروع للوصول إلى البيانات ومشروع لاختبارات الوحدة.

لكن في بعض الأحيان يكون من الحكمة الفصل بناءً على الخدمات (إذا كنت تستخدم بنية موجهة نحو الخدمة) مثل المصادقة والمبيعات وما إلى ذلك.

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

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

Answer 5

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

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

Answer 6

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

Answer 7

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

بالنسبة للمشاريع الكبيرة، لدي مشاريع ل

• الوصول إلى البيانات (نماذج)
• خدمات
• نهاية المقدمة
• الاختبارات

حصلت على النموذج من روب كونري وتطبيق واجهة المتجر الخاص به...يبدو أن العمل بشكل جيد حقا.

واجهة متجر mvc