คำถามติดแท็ก use-case

3
RPC-ish ใกล้จะเหมาะสมกว่า REST เมื่อใด
หลังจากดูการพูดคุยนี้ใน REST แล้ว Reuse and Serendipityโดย Steve Vinoski ฉันสงสัยว่ามีกรณีธุรกิจในโครงการกรีนฟิลด์สำหรับ (XML-) การตั้งค่า RPC-ish ที่ REST ไม่สามารถแก้ไขได้ในทางที่ดีขึ้น ปัญหา RPC สองสามอย่างที่เขากล่าวถึง: มุ่งเน้นที่ภาษา (จัดระบบให้เหมาะสมกับภาษาไม่ใช่วิธีอื่น ๆ ) "ทำให้ดูเป็นท้องถิ่น" (และรับมือกับความล้มเหลวและความหน่วงแฝงเป็นข้อยกเว้นมากกว่ากฎ) ตั้งใจที่จะเป็นภาษาที่เป็นอิสระ แต่ยังคงมี "การเรียกใช้ฟังก์ชัน" ข้ามภาษาเป็นส่วนผสมหลัก IDLสำเร็จรูป ภาพลวงตาของความปลอดภัยประเภท และอีกไม่กี่ ... เพียงเพิ่มบทละครลงเล็กน้อยผลการค้นหาทันใจของ Google สำหรับ RPC และ REST:

2
วิธีจัดการและประเมินความต้องการที่ไม่มีโครงสร้างที่ได้รับจากลูกค้า
หลายครั้งในระหว่างขั้นตอนการเสนอราคาของโครงการฉันได้รับข้อกำหนดของระบบซอฟต์แวร์จากผู้มีโอกาสเป็นลูกค้าของเราในรูปแบบที่ไม่มีโครงสร้างมากจากแหล่งต่าง ๆ [อีเมล, เอกสารคำ, excel] โดยปกติจะเป็นกลุ่มของ "การพัฒนาผลิตภัณฑ์" จากฝ่ายลูกค้าที่มาพร้อมกับ "โซลูชันที่เสนอ" เหล่านี้เพื่อแก้ไขปัญหาทางธุรกิจที่พวกเขามี ในขณะที่พวกเขาเป็นผู้เชี่ยวชาญในโดเมนธุรกิจหลายครั้งที่พวกเขาไม่มีทางแก้ไข ผลลัพธ์นี้ใน ข้อกำหนดเดียวกันหลายรุ่น ผสมสองข้อกำหนดเข้าเป็นหนึ่งเดียว ข้อกำหนดสองสามเวอร์ชันในภายหลังบรรทัดความต้องการที่รวมกันได้ถูกแยกออกอีกครั้งโดยแต่ละรายการจะมีส่วนเพิ่มเติมใหม่ คุณทำงานกับข้อกำหนดดังกล่าวที่เข้ามาและแยกออกเป็นกรณีการใช้งานที่เหมาะสมและก่อนการพัฒนาเริ่มต้นอย่างไร เครื่องมือใดที่เราสามารถใช้เพื่อติดตามประวัติของความต้องการเฉพาะตั้งแต่ครั้งแรกที่มันถูกสร้างขึ้นจนถึงเวลาที่มันจะตกผลึกเป็นกรณีการใช้งานที่เหมาะสม? การประเมินงานที่ตรงกับความต้องการที่ได้รับในรูปแบบดังกล่าวเป็นฝันร้ายที่สิ้นสุดลงในการทำผิดพลาดในการทำความเข้าใจข้อกำหนดอย่างถูกต้องและประเมินความพยายามกับสิ่งที่ถูกต้อง เมื่อเราชนะโครงการลูกค้าจะให้ความสำคัญกับความต้องการของพวกเขามากขึ้นและสามารถสื่อสารได้อย่างถูกต้อง สิ่งที่เกิดขึ้นในกรณีนี้คือฟังก์ชั่นบางอย่างอาจลดลงบางส่วนได้รับการปรับปรุงบางส่วนได้รับเทิร์นใหม่ทั้งหมด สิ่งนี้สามารถทำให้การประมาณการรายการงานบางส่วนเป็นโมฆะก่อนที่โครงการจะชนะ ฉันสนใจที่จะทราบว่ามีระบบใดบ้างที่เราสามารถสร้างแผนภูมิที่มีความต้องการเฉพาะและวิธีที่แต่ละสาขาส่งผลให้การประเมินแตกต่างกัน เคล็ดลับเครื่องมือและเทคนิคใด ๆ ที่ทำให้กิจกรรมนี้จัดการได้ง่ายขึ้นหรือไม่ ฉันแค่พยายามที่จะได้รับข้อมูลเชิงลึกจากคนที่มีประสบการณ์มากกว่าฉันในการจัดการความต้องการและการประเมินความพยายาม

3
สถาปัตยกรรมสะอาด - ใช้คลาสของเคสมากเกินไป
ฉันกำลังเข้าสู่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 …
15 java  android  use-case  mvp 
โดยการใช้ไซต์ของเรา หมายความว่าคุณได้อ่านและทำความเข้าใจนโยบายคุกกี้และนโยบายความเป็นส่วนตัวของเราแล้ว
Licensed under cc by-sa 3.0 with attribution required.