مستودع واحد مع C#: تنظيم الكود في مشاريع .NET

مستودع واحد مع C#: كيفية تنظيم الكود في مشاريع .NET

يواجه التطوير الحديث باستخدام C# و .NET بشكل متزايد خيارًا: تخزين جميع المشاريع المرتبطة في مستودع واحد (مستودع واحد) أو تقسيمها إلى مستودعات منفصلة (مستودعات متعددة). المستودع الواحد هو نهج يتم فيه تخزين كود العديد من التطبيقات والمكتبات والاختبارات والتكوينات في مستودع Git واحد. بالنسبة للحلول المؤسسية الكبيرة، أو الخدمات المصغرة، أو مكتبات NuGet، يمكن لهذا النهج أن يبسط بشكل كبير إدارة التبعيات، وإعادة الهيكلة، والنشر.

في هذه المقالة، سنناقش كيفية تنظيم مستودع واحد مع C# بشكل صحيح في نظام .NET البيئي، وسننظر في هيكل المجلدات، وإعداد المشاريع، و CI/CD، وأفضل الممارسات.

1. مزايا وعيوب المستودع الواحد في .NET

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

المزايا:

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

العيوب:

• نمو حجم المستودع. بمرور الوقت، يمكن أن يصبح الاستنساخ والتاريخ كبيرين جدًا.
• تعقيد CI/CD. يتطلب نظام بناء ذكيًا لتجنب إعادة بناء كل شيء مع كل التزام.
• صلاحيات الوصول. في مستودع واحد، يكون من الصعب التمييز بين صلاحيات الوصول للفرق المختلفة.

بالنسبة لمشاريع .NET، يكون المستودع الواحد مناسبًا بشكل خاص عندما يكون لديك مكتبة فئات مشتركة (مثل Domain أو Common)، والعديد من الخدمات المصغرة أو واجهات برمجة التطبيقات (API) التي تعتمد عليها.

2. هيكل المستودع الواحد لـ C# (.NET)

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

MyApp/├── .github/│   └── workflows/│       └── ci.yml├── src/│   ├── MyApp.Common/          # مكتبة مشتركة│   │   ├── MyApp.Common.csproj│   │   └── ...│   ├── MyApp.Api.Orders/      # خدمة مصغرة للطلبات│   │   ├── MyApp.Api.Orders.csproj│   │   └── ...│   └── MyApp.Api.Users/       # خدمة مصغرة للمستخدمين│       ├── MyApp.Api.Users.csproj│       └── ...├── tests/│   ├── MyApp.Common.Tests/│   │   ├── MyApp.Common.Tests.csproj│   │   └── ...│   └── MyApp.Api.Orders.Tests/│       ├── MyApp.Api.Orders.Tests.csproj│       └── ...├── Directory.Build.props       # إعدادات مشتركة لجميع المشاريع├── MyApp.sln                   # حل لـ Visual Studio└── README.md

النقاط الرئيسية:

• جميع المشاريع موجودة في مجلد src/، والاختبارات في tests/. هذا هو المعيار المعتمد في مجتمع .NET.
• الملف Directory.Build.props يحدد الخصائص المشتركة: TargetFramework، Nullable، ImplicitUsings، إصدارات الحزم، إلخ.
• ملف SLN واحد يبسط العمل في IDE، ولكن مع عدد كبير من المشاريع، يمكن تقسيمه إلى عدة حلول.

مثال على Directory.Build.props:

<Project>  <PropertyGroup>    <TargetFramework>net8.0</TargetFramework>    <Nullable>enable</Nullable>    <ImplicitUsings>enable</ImplicitUsings>    <TreatW