إزاي تبني تطبيقات Flutter ضخمة باستخدام Clean Architecture؟
أكيد مريت بالموقف ده: بدأت مشروع Flutter بسيط، وبعد فترة الكود بقى عبارة عن "سباجيتي" (Spaghetti Code). بتيجي تعدل حاجة في الـ UI، تلاقي الـ Logic باظ، ولما تيجي تغير الـ API، تلاقي نص التطبيق محتاج إعادة كتابة. ده الوجع الحقيقي اللي بيواجه أي مطور لما المشروع بيكبر. الحل السحري هنا هو الـ هندسة النظيفة (Clean Architecture).
Table of contents [Show]
يعني إيه Clean Architecture ببساطة؟
الفكرة كلها إننا بنقسم التطبيق لطبقات (Layers) مفصولة عن بعضها. كل طبقة ليها مسؤولية محددة، ومفيش طبقة بتعرف تفاصيل الطبقة اللي تحتها. الهدف إننا نخلي الـ Business Logic مستقل عن الـ UI وعن الـ Framework نفسه، وده بيخلي تطبيقك سهل جداً في الاختبار (Testing) والصيانة (Maintenance).
طبقات المشروع الأساسية في Clean Architecture
عشان نطبق ده في Flutter، بنقسم المشروع لثلاث طبقات رئيسية:
- طبقة البيانات (Data Layer): المسؤولة عن جلب البيانات سواء من API أو Local Database.
- طبقة النطاق (Domain Layer): دي "قلب" التطبيق، فيها الـ Entities والـ Use Cases، وممنوع تعتمد على أي مكتبة خارجية.
- طبقة العرض (Presentation Layer): مسؤولة عن الـ UI والـ State Management (زي BLoC أو Provider).
تطبيق عملي: هيكلة المجلدات
في مشاريع Flutter الكبيرة، يفضل نستخدم هيكلة المجلدات (Feature-first approach)، يعني كل ميزة في التطبيق (زي الـ Authentication) ليها المجلد الخاص بيها:
lib/
features/
auth/
domain/
data/
presentation/
الخطوة الأولى: Domain Layer
هنا بنعرف الـ كيانات (Entities) و العقود (Repositories Contracts). الميزة هنا إن الـ Domain ميعرفش إحنا بنجيب البيانات من فين، هو بس بيطلب البيانات وبيرجعها.
abstract class UserRepository {
Future getUserData();
}
الخطوة الثانية: Data Layer
هنا بننفذ الـ Repository، وبنتعامل مع الـ مصادر البيانات (Data Sources) سواء كانت Remote أو Local.
class UserRepositoryImpl implements UserRepository {
final RemoteDataSource remoteDataSource;
UserRepositoryImpl(this.remoteDataSource);
@override
Future getUserData() async {
return await remoteDataSource.fetchUser();
}
}
الخطوة الثالثة: Presentation Layer
هنا بنستخدم الـ منطق العرض (State Management). أنا بنصح دايماً باستخدام BLoC (Business Logic Component) لأنه بيخلي الـ UI منفصل تماماً عن الـ Logic، وده بيسهل عملية الـ Unit Testing.
ليه تتعب نفسك وتطبق Clean Architecture؟
عشان لما مديرك يطلب تغيير الـ API، أو تغير قاعدة البيانات، أو حتى تغير شكل الـ UI بالكامل، تقدر تعمل ده في جزء بسيط من الكود من غير ما تكسر باقي المشروع. التطبيق بيبقى "قابلاً للاختبار" (Testable) و"قابلاً للتوسع" (Scalable).
نصيحة من أخ لمبرمج زميل
متحاولش تطبق الـ Clean Architecture في كل مشروع صغير أو تجريبي، لأنها هتخلي الوقت اللي بتضيعه في الـ Setup أكتر من وقت البرمجة. استخدمها في المشاريع الكبيرة (Enterprise Apps) اللي متوقع تكمل معاك لفترة طويلة. اتعلم الـ Dependency Injection (زي GetIt أو Injectable) عشان تسهل على نفسك ربط الطبقات ببعضها. البرمجة مهارة تراكمية، ابدأ بتنظيم الكود بتاعك النهاردة، هتلاقي فرق كبير في أدائك بعد سنة من دلوقتي.
