

โครงการนี้เป็นการดำเนินการอย่างหลวม ๆ ของสถาปัตยกรรมที่สะอาดตามที่นำเสนอในหนังสือของฉันสถาปัตยกรรมสะอาดสำหรับ Android มันเป็นโครงการ Android พื้นเมืองที่เขียนใน Kotlin มันแสดงให้เห็นถึงหลักการสำคัญที่นำเสนอในหนังสือและวิธีที่พวกเขานำไปใช้กับโครงการชีวิตจริง
ฉันจะพยายามรักษาโครงการนี้ให้ทันสมัยและใช้งานเพื่อแสดงให้เห็นถึงจุดแข็งของสถาปัตยกรรม: ความสามารถในการปรับขนาด ความสามารถในการทดสอบ และ ความยืดหยุ่น เมื่อมันมาถึงการเลือกโซลูชั่นของบุคคลที่สาม
ความเรียบง่าย
" ความซับซ้อนที่แนะนำที่นี่คือ overkill! "
ฉันเห็นด้วย. หากนี่เป็นโครงการ สุดท้าย ซึ่งจะไม่มีการเพิ่มฟังก์ชั่นใหม่มาก่อน สถาปัตยกรรมที่สะอาด จะมีความซับซ้อนมากเกินไป อย่างไรก็ตามความจริงก็คือโครงการมือถือ ไม่ค่อย ดี ความคิดเห็นของผู้ใช้ข้อกำหนดด้านการตลาดเทคโนโลยีใหม่ - ปัจจัยเหล่านี้และอื่น ๆ ทั้งหมดนำไปสู่การเปลี่ยนแปลงอย่างต่อเนื่องในเกือบทุกโครงการ ดังนั้นสิ่งที่อาจดูเหมือนซับซ้อนมากเกินไปจะให้รางวัลเราเมื่อถึงเวลาสำหรับการเปลี่ยนแปลง นี่จะเป็นเมื่อ สถาปัตยกรรมที่สะอาด ส่องแสง
ในฐานะที่เป็นหมายเหตุด้านข้าง: ในบางวิธีฉันมีโครงการนี้ โดยเจตนา มากเกินไปโดยการแนะนำเทคโนโลยีที่แตกต่างกัน เป้าหมายคือการแสดงให้เห็นว่าแม้ในสถานการณ์จริงในชีวิตจริงซึ่งโครงการอาจเติบโตขึ้นเมื่อเวลาผ่านไปเพื่อรวมโซลูชันเทคโนโลยีมากกว่าหนึ่งวิธีสถาปัตยกรรมยังคงใช้งานได้
แผนที่เป็นคลาส กับ ฟังก์ชั่นการขยายการแมป
เมื่อแมประหว่างรุ่นเรามีหลายตัวเลือก การตัดสินใจหลักคือระหว่างคลาส Mapper และฟังก์ชั่นส่วนขยายการแมป
ในขณะที่ฟังก์ชั่นการขยายมีความรัดกุมมากขึ้นโดยใช้สำหรับการแมป จำกัด ตัวเลือกของเราในการทดสอบเฟรมเวิร์ก (ตัวอย่างเช่น Mockito ไม่สามารถใช้ฟังก์ชั่นคงที่แบบคงที่)
วิธีการเกี่ยวกับการฉีดฟังก์ชั่นส่วนขยาย Mapper? เราสามารถทำได้ อย่างไรก็ตามสิ่งนี้จะช่วยขจัดประโยชน์ของความกระชับเกือบทั้งหมด นอกจากนี้ยังทำให้การนำทางไปยังการใช้งานยากขึ้น
ดังนั้นฉันจึงเลือกใช้คลาส Mapper คอนกรีต Verbose เล็กน้อย
ข้ามส่วนประกอบสถาปัตยกรรมของ Google
ปัญหาที่ยิ่งใหญ่ที่สุดของส่วนประกอบสถาปัตยกรรมของ Google คือพวกเขารั่วรายละเอียด Android ลงในชั้นนำเสนอ สิ่งนี้จะช่วยป้องกันไม่ให้เลเยอร์การนำเสนอไม่เป็นผู้ไม่เชื่อเรื่องพระเจ้า UI อย่างแท้จริง
ปัญหาอีกประการหนึ่งขององค์ประกอบสถาปัตยกรรมคือพวกเขาให้ความรับผิดชอบมากเกินไปกับ ViewModel พวกเขาทำให้มันยังคงระบุว่ามันไม่ได้เป็นเจ้าของนำไปสู่ข้อบกพร่องการซิงโครไนซ์ข้อมูลที่เป็นไปได้
ด้วยเหตุผลเหล่านี้ในขณะที่ยังคงติดตาม MVVM โครงการนี้อาศัย การไหลของ Kotlin มากกว่า Livedata และใช้ ViewModels บริสุทธิ์มากกว่าของ Google
กรอบการเยาะเย้ย
ทั้ง mockito-kotlin และ mockk ถูกใช้ในโครงการนี้เพื่อแสดงให้เห็นว่าการใช้งานแต่ละอย่างจะดูอย่างไร
ความชอบส่วนตัวของฉันยังคงเป็น mockito-kotlin ฉันพบว่ารหัสอ่านและติดตามได้ง่ายขึ้นเมื่อใช้งาน ในช่วงเวลาของการเขียนตัดสินจากจำนวนดาวในแต่ละพื้นที่เก็บข้อมูลอุตสาหกรรมดูเหมือนจะเอนไปทาง Mockk
ฉันถูกถามเกี่ยวกับการใช้ ของปลอม ฉันได้สำรวจของปลอมและพบว่าพวกเขามีความผิดปกติมากเกินไปและแพงเกินไปที่จะรักษา
กรอบการฉีดพึ่งพา
ส่วนสำคัญของแอพที่ทันสมัยที่สุดการฉีดพึ่งพา (DI) ช่วยให้เราได้รับวัตถุที่สร้างแอพของเรา นอกจากนี้ยังช่วยจัดการขอบเขตของพวกเขา ตัวเลือกที่ได้รับความนิยมมากที่สุดในโลก Android คือ Hilt (ซึ่งสร้างขึ้นบนกริช) และ Koin
Hilt ได้รับเลือกด้วยเหตุผลหลักสองประการ:
XML vs Jetpack Compose
ทำไมไม่ทั้งคู่? ฉันยังมีข้อกังวลมากมายเกี่ยวกับ การแต่งเพลงเจ็ทแพ็ค ถึงกระนั้นมันก็เป็นสิ่งสำคัญสำหรับฉันที่จะแสดงสถาปัตยกรรมที่นำเสนอทำงานได้ดีโดยไม่คำนึงถึงกลไก UI ที่เลือก ในฐานะแบบฝึกหัดฉันขอเชิญคุณลองและแทนที่เลเยอร์ UI จากการเขียนเป็น XML หรือในทางกลับกันโดยไม่ต้องอัปเดตเลเยอร์การนำเสนอ
สถาปัตยกรรมที่สะอาดสำหรับ Android บน Amazon
สถาปัตยกรรมที่สะอาดในบล็อก CoDer ที่สะอาด
ยินดีต้อนรับการมีส่วนร่วมในโครงการนี้ โปรดรายงานปัญหาหรือส้อมใด ๆ เพื่อทำการเปลี่ยนแปลงและยกคำขอดึง
โครงการนี้มีการแจกจ่ายภายใต้ข้อกำหนดของใบอนุญาต MIT ดูใบอนุญาตสำหรับรายละเอียด