สถาปัตยกรรมสะอาด - ใช้คลาสของเคสมากเกินไป

ฉันกำลังเข้าสู่Clean Architectureและยกระดับ Android ของฉันจาก MVC เป็นMVPแนะนำ DI กับ Dagger 2, Reactivity with RxJava 2 และแน่นอน Java 8

ในสถาปัตยกรรมที่สะอาด MVPมีเลเยอร์ระหว่างเอนทิตี (ในดาต้าสโตร์) และผู้นำเสนอที่ควรเข้าถึง ชั้นนี้คือ"การใช้กรณี" กรณีการใช้งานเป็นส่วนติดต่อแบบอุดมคติซึ่งใช้การดำเนินการหนึ่งอย่างกับหนึ่งเอนทิตี้

ฉันยังรู้ว่า Clear Architecture " กำลังกรีดร้อง " ในแง่ของโปรเจ็กต์นั้นสามารถอ่านได้สูงมากเนื่องจากมีคลาสจำนวนมากในพวกเขา

ตอนนี้อยู่ในโครงการของฉันฉันมีบางอย่างเช่น6 หน่วยงานต่าง ๆและแน่นอนแต่ละพื้นที่เก็บข้อมูลกิจการอย่างน้อย 4 วิธี (มักจะได้รับเพิ่มลบปรับปรุง) เพื่อเข้าถึงพวกเขา .. ดังนั้น 6 * 4 = 24

หากสิ่งที่ฉันเข้าใจจนถึงปัจจุบันของ Clean Architecture ฉันจะมี 24 UseCase

นี่เป็นคลาสจำนวนมากหากเปรียบเทียบกับคอนโทรลเลอร์เพียง 6 ตัวใน MVC ..

ฉันต้องใช้เคส 24 ครั้งจริง ๆ หรือไม่

ฉันจะขอบคุณคำชี้แจงจากใครบางคนที่ใช้มันไปกับความสำเร็จแล้ว

ขอบคุณแจ็ค

— Jackie Degl'Innocenti
แหล่งที่มา

คุณสามารถโพสต์ลิงค์ไปยังหน้าที่อธิบายรายละเอียดการใช้เคสเหล่านี้พร้อมรหัสตัวอย่างได้หรือไม่?

— Robert Harvey

ฉันใช้ Google เป็นจำนวนมาก แต่ส่วนใหญ่: ตัวอย่างแอปนี้และบทความที่เกี่ยวข้อง: github.com/jshvarts/OfflineSampleApp ; บทความนี้: proandroiddev.com/… ; proandroiddev.com/… ; การพูดคุยนี้: youtube.com/watch?v=TvsOsgd0--c&feature=youtu.be ; และบทความนี้ด้วย: adityaladwa.wordpress.com/2016/10/25/ …

— Jackie Degl'Innocenti

ไม่มีแอปหรือบทความตัวอย่างที่คุณอ้างถึงมีส่วนเกี่ยวข้องกับ Clean Architecture อย่างไรก็ตามพวกเขาพูดถึงการเขียนโปรแกรมปฏิกิริยา

— Robert Harvey

แอพตัวอย่างทำด้วยกระบวนทัศน์ Clean Architecture แน่นอน .. บทความอื่น ๆ ส่วนใหญ่ .. คุณต้องการเห็นอะไร @RobertHarvey?

— Jackie Degl'Innocenti

อ่านคำตอบของฉันด้านล่างและตอบกลับ

— Robert Harvey

คำตอบ:

ฉันต้องใช้เคส 24 ครั้งจริง ๆ หรือไม่

แต่ถ้าทุกสิ่งที่คุณเขียนCRUD

อ้างอิงจากแผนภาพด้านล่าง:

การยืนยันของคุณคือคุณจะมีเอนทิตีที่แตกต่างกันหกแบบและ 4 วิธี (สร้างอ่านอัปเดตและลบ) สำหรับแต่ละเอนทิตี แต่นั่นเป็นจริงในวงกลมสีเหลืองที่อยู่ตรงกลางของไดอะแกรม (เลเยอร์นิติบุคคล) ไม่มีประโยชน์ที่จะสร้างวิธีการ 24 วิธีในเลเยอร์การใช้เคสที่ผ่านการเรียก CRUD ไปยังเลเยอร์เอนทิตีเท่านั้น

กรณีการใช้งานไม่ใช่ "เพิ่มบันทึกลูกค้า" กรณีการใช้งานมีมากขึ้นตามบรรทัดของ"ขายสินค้าให้กับลูกค้า" (ซึ่งเกี่ยวข้องกับลูกค้าผลิตภัณฑ์และเอนทิตีสินค้าคงคลัง) หรือ"พิมพ์ใบแจ้งหนี้" (ซึ่งเกี่ยวข้องกับหน่วยงานเดียวกันนอกเหนือจากรายการส่วนหัวของใบแจ้งหนี้และใบแจ้งหนี้ )

เมื่อคุณสร้าง Use Cases คุณควรคิดถึงธุรกรรมทางธุรกิจไม่ใช่วิธี CRUD

อ่านเพิ่มเติม
รวม - กลุ่มของวัตถุโดเมนที่สามารถถือว่าเป็นหน่วยเดียว

— โรเบิร์ตฮาร์วีย์
แหล่งที่มา

คุณใช้เวลาคิดมากเกี่ยวกับรูปแบบการปฏิบัติและสถาปัตยกรรมและเวลาไม่พอที่จะคิดถึงการออกแบบซอฟต์แวร์ขั้นพื้นฐาน สิ่งที่คุณต้องมีคือวิธีการรวบรวมการดำเนินธุรกิจตามที่ฉันอธิบายไว้ในคำตอบ

— Robert Harvey

มันไม่ใช่คำถามของการเลือกสถาปัตยกรรม ความเห็นส่วนตัวของฉัน: การทำงานของ CRUD ที่เปลือยเปล่าควรพูดกับ Entity Layer โดยตรง แน่นอนว่านี่อาจเป็นการละเมิดสถาปัตยกรรมที่สะอาด

— Robert Harvey

คุณไม่มีประเด็น สถาปัตยกรรมเป็นเพียงวิธีในการจัดระเบียบรหัส คุณแก้ปัญหาด้วยการเขียนรหัสไม่ใช่การต่อสู้กับสถาปัตยกรรม

— Robert Harvey

เฮ้โรเบิร์ตมันไม่ค่อยดีนักที่คุณคิดว่าฉันไม่ได้เขียนโค้ด หัวข้อคำตอบของฉันอยู่ที่สถาปัตยกรรมและเราไม่ได้อยู่ในนั้น ด้วยความจริงใจฉันค้นหาความคิดเห็นล่าสุดของคุณทำให้เข้าใจผิดและหูหนวกจริงๆ คำถามเกี่ยวกับ UseCase ใน Clean Arch ไม่ใช่การเขียนโค้ด หากคุณกำลังพยายามสื่อสารบางสิ่งโปรดอธิบายให้ดีขึ้นเพราะฉันไม่มีความคิดเห็น IMHO เป็นไปไม่ได้ที่จะหลีกเลี่ยงการพิจารณาสถาปัตยกรรมในขณะที่กำลังพัฒนาซอฟต์แวร์หรืออย่างน้อย devs ที่ดีไม่เพียงแค่เขียนโค้ดจำนวนมาก นอกจากนี้ฉันถามคำถามที่เฉพาะเจาะจงในความคิดเห็นของฉันคุณสามารถตอบได้ไหม ขอบคุณ

— Jackie Degl'Innocenti

วิธีแก้ปัญหาที่คุณโพสต์ (แอพออฟไลน์ก่อน) ไม่ได้มีส่วนเกี่ยวข้องกับ Clean Architecture มากนัก คุณจะไม่พบทางออกสำหรับปัญหานั้นในแผนภาพ Clean Architecture

— Robert Harvey

คุณถูกต้องถ้าทุก CRUD-Operation ถูกแปลใน UseCase เดียว แต่ UseCase อาจประกอบด้วย CRUD-Operations หลายตัว

UseCase เป็นรูปแบบที่แยกจากกันรวบรวมข้อมูลจากแหล่งข้อมูลที่แตกต่างกันและเตรียมการสื่อสารไปยังที่เก็บข้อมูล สามารถมีส่วนร่วม CRUD-Operations ได้หลายรายการ

ดังนั้นให้นึกถึง UseCase ที่สร้างใบแจ้งหนี้ให้กับลูกค้าและสร้างลูกค้าด้วยเพราะเขา / เธอไม่มีอยู่ในระบบ คุณมีหนึ่ง UseCase ที่ส่งผลให้เกิดการสร้างการดำเนินงานอย่างน้อยสองรายการในหนึ่งธุรกรรม

— oopexpert
แหล่งที่มา

ดังนั้นรูปแบบที่คุณจะแนะนำอีกครั้งสำหรับตัวอย่างของ CRUD กับเอนทิตีหลาย ๆ

— Jackie Degl'Innocenti

มุมมองส่วนตัวของฉันเกี่ยวกับเรื่องนี้คือ: ฉันไม่มีปัญหาที่จะมีชั้นเรียนจำนวนมากตราบใดที่พวกเขาไม่ได้ละเมิด SRP (หลักการความรับผิดชอบเดียว) แต่ฉันใช้เวลาส่วนใหญ่จะกำหนด Usecases "สร้างเอนทิตี", "อัปเดตเอนทิตี", "ลบเอนทิตี" และ "อัปเดตเอนทิตี" เป็นเอนทิตีง่าย "จัดการเอนทิตี X" บ่อยครั้งที่คุณมี UI เดียวเพื่อจัดการหนึ่งเอนทิตี้ แต่นั่นคือสิ่งที่ UseCase ของคุณควรกำหนด: วิธีจัดการกับภาระงานที่เป็นประโยชน์สำหรับธุรกิจของคุณ

— oopexpert

ตกลงดังนั้นการมี Case การใช้งานที่จัดการการดำเนินงานที่แตกต่างกันดูเหมือนจะไม่เป็นการละเมิด SRP เนื่องจากดูเหมือนว่าจะ "รวม" วิธีการต่าง ๆ (และการไหล) ที่แตกต่างกันใน UseCase เดียวกันโดยไม่มีการไหลใด ๆ .. แต่ด้วยวิธีนี้เราไม่เพียงสร้างคอนโทรลเลอร์แทน UseCase ใช่ไหม .. ความคิด .. บางทีกรณีการใช้งานต้องถูกมองว่าเป็นเลเยอร์และเลเยอร์นั้นก็ต้องเคารพ SRP แต่ก็สามารถใช้วิธีการต่าง ๆ ได้เช่นกัน ฉันต้องการมีแหล่งข้อมูลหรือบทความเกี่ยวกับเรื่องนี้

— Jackie Degl'Innocenti

A Usecase เป็นตัวควบคุม ความแตกต่างเพียงอย่างเดียวคือว่า usecase นั้นมาจากมุมมองทางธุรกิจและคอนโทรลเลอร์เป็นมุมมองทางเทคนิคของมัน จุดเน้นของ usecase คือสิ่งที่สร้างมูลค่าทางธุรกิจ ดังนั้น usecase จึงเป็นการนำเอาคอนโทรลเลอร์เชิงมูลค่ามาใช้ในธุรกิจ

— oopexpert

เห็นด้วยตัวควบคุม HTTP เป็นวิธีการจัดการ I / O นอกจากนี้ยังสามารถมีคำสั่งคอนโซลปฏิกิริยาเหตุการณ์และอื่น ๆ แชนเนล I / O ทั้งหมดเหล่านี้เรียกชื่อผู้ใช้เดียวกัน usecase เป็นตัวควบคุมสำหรับตรรกะทางธุรกิจไม่ทราบเกี่ยวกับ I / O แชนเนลที่ถูกเรียกจาก แต่มันรู้วิธีการจัดระเบียบเอนทิตีโดเมนเพื่อทำงาน

— Dmitriy Lezhnev

คำจำกัดความการใช้งานของคุณผิดใช้กรณีใช้เป็นคลาสที่ใช้กฎทางธุรกิจไม่จำเป็นต้องเป็นการดำเนินการ CRUD อาจเป็นการดำเนินการหลายขั้นตอนที่ซับซ้อน

— Buckstabue
แหล่งที่มา

ประโยคของคุณไม่ได้หมายถึงการแก้ปัญหาเมื่อคุณจำเป็นต้องใช้การดำเนินงานที่มีลักษณะคล้าย Crud ที่หลากหลายแม้ว่าการพิจารณาของคุณอาจพบความสัมพันธ์กับข้อเท็จจริงที่ว่า Case การใช้งานควรสังเกตรูปแบบที่เราสามารถเข้าถึงการดำเนินการที่ซับซ้อน แม้กระทั่งหลายขั้นตอน

— Jackie Degl'Innocenti