CleanArchitectureForAndroid
1.0.0
هذا المشروع هو تطبيق فضفاض للهندسة المعمارية النظيفة كما هو موضح في كتابي ، Clean Architecture for Android. إنه مشروع Android الأصلي مكتوب في Kotlin. إنه يوضح المبادئ الرئيسية المقدمة في الكتاب وكيف تنطبق على مشروع الحياة الحقيقية.
سأسعى لإبقاء هذا المشروع محدثًا واستخدامه لإظهار نقاط القوة في الهندسة المعمارية: قابلية التوسع ، قابلية الاختبار والمرونة عندما يتعلق الأمر باختيار حلول الطرف الثالث.
بساطة
" التعقيد الذي تم تقديمه هنا هو مبالغة! "
أنا موافق. إذا كان هذا مشروعًا نهائيًا ، فلن تتم إضافة أي وظيفة جديدة على الإطلاق ، فستكون العمارة النظيفة معقدة للغاية لذلك. ومع ذلك ، فإن الواقع هو أن مشروع الهاتف المحمول نادراً ما يكون نهائيًا. ملاحظات المستخدم ومتطلبات التسويق والتقنيات الجديدة - تؤدي هذه العوامل وغيرها إلى تغييرات مستمرة في كل مشروع تقريبًا. وهكذا ، ما قد يبدو الآن وكأنه الكثير من التعقيد سوف يكافئنا عندما يحين وقت التغيير. سيكون هذا عندما تشرق العمارة النظيف .
كملاحظة جانبية: في بعض النواحي ، قمت بإفراط في تعقيد هذا المشروع عن قصد من خلال تقديم تقنيات مختلفة. كان الهدف هو إظهار كيف ، حتى في سيناريوهات الحياة الواقعية ، حيث قد يكون المشروع قد نما بمرور الوقت ليشمل أكثر من حل تكنولوجي واحد ، لا تزال الهندسة المعمارية تعمل.
تعيينات كطبقات مقابل تعيين وظائف التمديد
عند رسم الخرائط بين النماذج ، لدينا العديد من الخيارات. القرار الأساسي هو بين فئات MAPPER ووظائف تمديد رسم الخرائط.
على الرغم من أن وظائف التمديد أكثر إيجازًا ، إلا أن استخدامها لرسم الخرائط يحد من اختياراتنا في أطراف الاختبار (على سبيل المثال ، لا يمكن لخليص وظائف ثابتة).
ماذا عن حقن وظائف امتداد Mapper؟ يمكننا أن نفعل ذلك. ومع ذلك ، فإن هذا يزيل فوائد إيجاز تمامًا تقريبًا. كما أنه يجعل التنقل إلى التنفيذ أكثر صعوبة.
وهكذا ، اخترت فئات الخرسانة الخرسانية الأكثر مطوّلة قليلاً.
تخطي مكونات الهندسة المعمارية من Google
أكبر مشكلة في مكونات الهندسة المعمارية من Google هي أنها تسرب تفاصيل Android إلى طبقة العرض التقديمي. هذا يمنع طبقة العرض التقديمي من كونها واجهة المستخدم حقًا.
مسألة أخرى مع مكونات الهندسة المعمارية هي أنها تعطي الكثير من المسؤولية عن ViewModel. إنها تجعلها مستمرة لا تملكها ، مما يؤدي إلى حشرات مزامنة البيانات المحتملة.
لهذه الأسباب ، بينما لا يزال يتابع MVVM ، يعتمد هذا المشروع على تدفقات Kotlin بدلاً من Livedata ، ويقوم بتنفيذ ViewModels Pure بدلاً من Google.
إطار السخرية
يتم استخدام كل من Mockito-Kotlin و Mockk في هذا المشروع لإظهار كيفية استخدام كل منها.
يظل تفضيلي الشخصي mockito-kotlin . أجد أن الكود أسهل في القراءة والمتابعة عند استخدامه. في وقت كتابة هذا التقرير ، بالحكم على عدد النجوم على كل مستودع ، يبدو أن الصناعة تميل نحو موكك.
سئلت عن استخدام مزيفة . لقد استكشفت مزيفة ، ووجدت أنها مطوّلة بشكل مفرط ومكلفة للغاية.
إطار حقن التبعية
جزء مهم من معظم التطبيقات الحديثة ، يساعدنا حقن التبعية (DI) في الحصول على الكائنات التي تنشئ تطبيقنا. كما أنه يساعد في إدارة نطاقهم. الخيارات الأكثر شيوعًا في عالم Android هي hilt (التي تم بناؤها فوق الخنجر) و Koin.
تم اختيار hilt لسببين رئيسيين:
XML vs Jetpack Compens
لماذا لا كلاهما؟ لا يزال لدي الكثير من المخاوف حول jetpack compens . ومع ذلك ، كان من المهم بالنسبة لي إظهار أن الهندسة المعمارية المقدمة تعمل بشكل جيد بغض النظر عن آلية واجهة المستخدم المختارة. كتمرين ، أدعوك لمحاولة استبدال طبقة واجهة المستخدم من تأليف XML أو العكس دون تحديث طبقة العرض التقديمي.
بنية نظيفة لنظام Android على Amazon
الهندسة المعمارية النظيفة على مدونة المبرمج النظيفة
المساهمات في هذا المشروع مرحب بها. لا تتردد في الإبلاغ عن أي مشكلات أو شوكة لإجراء تغييرات ورفع طلب سحب.
يتم توزيع هذا المشروع بموجب شروط ترخيص معهد ماساتشوستس للتكنولوجيا. انظر الترخيص. md للحصول على التفاصيل.
