แนวทางการพัฒนา: อินเทอร์เฟซผู้ใช้ในหรือโมเดลของโดเมน?

ในขณะที่ฉันไม่เคยส่งมอบอะไรเลยโดยใช้ Smalltalk เวลาสั้น ๆ ที่ฉันเล่นด้วยมันทิ้งร่องรอยไว้ วิธีเดียวที่จะอธิบายประสบการณ์คือ MVC ตามที่ตั้งใจไว้ โดยพื้นฐานแล้วการยกของหนักทั้งหมดสำหรับแอปพลิเคชันของคุณจะทำในออบเจ็กต์ทางธุรกิจ (หรือแบบจำลองโดเมนหากคุณมีแนวโน้มมาก) การควบคุมมาตรฐานถูกผูกไว้กับวัตถุทางธุรกิจในบางวิธี ตัวอย่างเช่นกล่องข้อความถูกแมปไปยังเขตข้อมูลของวัตถุ (เขตข้อมูลนั้นเป็นวัตถุเพื่อให้ง่ายต่อการทำ) ปุ่มจะแมปกับวิธีการ ทั้งหมดนี้ทำด้วย API ที่เรียบง่ายและเป็นธรรมชาติ เราไม่ต้องคิดเกี่ยวกับวัตถุที่มีผลผูกพัน ฯลฯ มันใช้งานได้

แต่ในภาษาและ APIs ที่ใหม่กว่านั้นคุณจะถูกบังคับให้คิดจากภายนอกสิ่งแรกคือ C ++ และ MFC และขณะนี้มี C # และ WPF แล้ว Microsoft ได้รับโลกของนักพัฒนาติดอยู่ใน GUI builders ซึ่งคุณสร้างแอปพลิเคชันของคุณ . การพัฒนา Java Swing นั้นไม่แตกต่างกันเพียงคุณเท่านั้นที่เขียนโค้ดเพื่อสร้างอินสแตนซ์ของการควบคุมในแบบฟอร์มด้วยตัวคุณเอง สำหรับบางโครงการอาจไม่เคยมีรูปแบบโดเมนเลยแม้แต่แค่ตัวจัดการเหตุการณ์ ฉันอยู่ในและรอบ ๆ โมเดลนี้สำหรับผู้ดูแลส่วนใหญ่ของฉัน

แต่ละวิธีบังคับให้คุณคิดต่างกัน ด้วยวิธีการ Smalltalk โดเมนของคุณจะฉลาดในขณะที่ GUI ของคุณเป็นใบ้ ด้วยวิธีการเริ่มต้นของ VisualStudio GUI ของคุณจะฉลาดในขณะที่รูปแบบโดเมนของคุณ (ถ้ามี) ค่อนข้างจะเป็นโลหิตจาง

นักพัฒนาหลายคนที่ฉันทำงานด้วยเห็นคุณค่าในแนวทางของ Smalltalk และพยายามใช้วิธีการดังกล่าวในสภาพแวดล้อมของ VisualStudio WPF มีคุณสมบัติการเชื่อมโยงแบบไดนามิกบางอย่างที่ทำให้เป็นไปได้ แต่มีข้อ จำกัด รหัสบางอย่างที่อยู่ในรูปแบบโดเมนจะสิ้นสุดลงในคลาส GUI

ดังนั้นคุณออกแบบ / พัฒนารหัสของคุณด้วยวิธีใด ทำไม?

• GUI ก่อน การโต้ตอบกับผู้ใช้เป็นสิ่งสำคัญยิ่ง
• โดเมนก่อน ฉันต้องแน่ใจว่าระบบนั้นถูกต้องก่อนที่เราจะใส่ UI ลงไป

มีข้อดีและข้อเสียสำหรับวิธีการอย่างใดอย่างหนึ่ง รูปแบบโดเมนเหมาะสมกับที่นั่นด้วยมหาวิหารคริสตัลและพายในท้องฟ้า GUI พอดีกับที่นั่นด้วยความรวดเร็วและสกปรก (บางครั้งก็สกปรกจริงๆ)

และสำหรับโบนัสเพิ่มเติม: คุณแน่ใจได้อย่างไรว่ารหัสนั้นสามารถคงไว้ได้?

ทั้ง

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

ผมขอสร้างภาพเพื่อทำให้แนวคิดนี้ชัดเจน

  +------+
  |  UI  | <- Think about how to make an effective user interface
  +------+
      |
      |
 +----------+
 | Contract | <--- This part over here is really REALLY important, man!
 +----------+
      |
      |
+--------------+
| Domain model | <- Think about what the user needs
+--------------+ 

ด้วยวิธีนี้คุณสามารถใช้งาน UI ได้อย่างซ้ำ ๆ และโมเดลโดเมนแยกจากกันถ้าพื้นกลางทำให้ชัดเจนว่าข้อมูลใดที่ UI สามารถรับได้

เหตุผลที่ฉันเห็นว่าทำไมบางโครงการกลายเป็นunmaintainableเนื่องจากส่วนต่อประสานระหว่างข้อมูลและงานนำเสนอถูกรีบหรือไม่ทำงาน (ด้วยรหัสการจัดการข้อมูลโดยตรงอยู่ใน UI) ฉันเคยเห็นโครงการมากมายที่รหัสฐานข้อมูลอยู่ในรหัสฟอร์มที่ฉันหมดศรัทธาในมนุษยชาติ มีเพียงไม่กี่โครงการที่ฉันเห็นว่ามีพื้นกลางที่เข้มงวดนี้คืนค่าที่สูญเสียศรัทธา

มันไม่สำคัญเลยว่าคุณจะเริ่มจากจุดไหนก่อน ... สิ่งที่สำคัญคือคุณมีข้อกังวลที่ชัดเจน สัญญาที่อยู่ตรงกลางนั้นกำหนดแอพพลิเคชั่นหรือระบบในมือ ลองนึกถึงภาพนั้นก่อนที่จะจากล่างขึ้นบนหรือบนลงล่าง

โดเมนก่อน ฉันต้องแน่ใจว่าระบบนั้นถูกต้องก่อนที่เราจะใส่ UI ลงไป

ไม่มีสิ่งใดสามารถทำงานได้ - ยกเว้นในกรณีง่าย ๆ

การเริ่มต้นจาก UI มักจะนำไปสู่ซอฟต์แวร์ที่มีความเปราะบางและบั๊กซึ่งอาจดูสนุกสนาน แต่มักมีปัญหาร้ายแรงในรุ่น

ไม่ใช่ว่า UI แรกจะถึงความล้มเหลว - ถ้าโมเดลนั้นง่ายพอ UI สามารถสร้างขึ้นได้ก่อนด้วยความมั่นใจว่าโมเดลจะทำงานได้ดีในที่สุด

ไม่ว่าในกรณีใดโมเดลที่ไม่สามารถจินตนาการได้อย่างง่ายดายจะต้องสร้างขึ้นก่อน

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

ขึ้นอยู่กับแอพพลิเคชั่นที่ใช้งานจริง

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

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

บ่อยครั้งในช่วงปลายของการพัฒนาวงจรวนซ้ำขนาดเล็กในการพัฒนา (การต่อสู้, Kanban, ฯลฯ .. ) ส่วนหน้าและส่วนหลังนั้นทำขนานกัน มันเกี่ยวกับการให้สิ่งที่คุณต้องการสำหรับการทำซ้ำ ไม่คำนึงถึงการสร้างมันในกรณีที่เราต้องการมันเข้ามาใกล้ ในแนวทางคู่ขนานปลายทั้งสองอยู่ใกล้ชิดกันมากตลอดการพัฒนาซึ่งสามารถบรรเทาความต้องการการเปลี่ยนแปลงอย่างต่อเนื่องเมื่อปลายด้านหน้าและด้านหลังผสาน นี่เป็นวิธีที่ฉันชอบเมื่อเป็นไปได้

คุณพูดถึง ...

... WPF มีคุณสมบัติการเชื่อมโยงแบบไดนามิกที่ทำให้มันเป็นไปได้; แต่มีข้อ จำกัด รหัสบางอย่างที่เป็นเจ้าของในรูปแบบโดเมนจะสิ้นสุดลงในชั้นเรียน GUI ...

ไม่แน่ใจว่าสิ่งที่คุณหมายถึงบางอย่าง ? WPF และ SL ถูกบันทึกไว้สำหรับฟังก์ชันการรวม มันไม่มีที่สิ้นสุด หากคุณถูกบังคับให้วางรหัสในมุมมองของคุณในแอปพลิเคชัน WPF ที่ใช้ MVVM ดังนั้นบางสิ่งจำเป็นต้องได้รับการแก้ไข พฤติกรรมที่แนบมาเป็นวิธีหนึ่งในการใช้พฤติกรรมโดยไม่ต้องผูกเหตุการณ์ไว้ในมุมมองเช่นเดียวกับวิธีอื่น ๆ ในการทำให้มุมมองของคุณยังคงสะอาดอยู่เสมอ

ปลายด้านหน้าจากท่าทางโต้ตอบกับผู้ใช้ควรจะมีอะไรจะทำอย่างไรกับการดำเนินงานสิ้นสุดหลัง ด้านหลังสิ้นสุดงาน แต่เพียงผู้เดียวไปยังส่วนหน้าคือการจัดหาข้อมูลผ่านการประมวลผลข้อมูลหรือวิธีการอื่น สิ่งนี้จะเชื่อมโยงกลับไปยังประเภทของแอปพลิเคชันที่กำลังพัฒนา

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

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

เราพยายามผลักดันซอฟต์แวร์ของเราด้วยการทดสอบอัตโนมัติ การทดสอบ UI อัตโนมัตินั้นใช้เวลาค่อนข้างมาก สคริปต์เพื่อตรวจสอบค่าบางอย่างบนคอนโซลนั้นง่ายขึ้น

โดยที่ในใจเราค่อนข้างระมัดระวังในการแยกตรรกะทางธุรกิจออกจาก UI

ฉันจำได้ครั้งหนึ่งว่ามีนักพัฒนานำตะโกนใส่ฉันว่าสถาปัตยกรรม Document / View นั้นล้าสมัยเมื่อฉันแนะนำว่าเราจำเป็นต้องหยุดการผูกรหัสธุรกิจทั้งหมดของเรากับ UI (และเราใช้ win32 ใน C ++ ในเวลานั้น) สิ่งก็ไม่ได้เป็นปัญหาของเรา) ฉันรู้สึกตะลึงงัน

IMNSHO ไม่มีข้อแก้ตัวใด ๆ หากไม่มีอย่างน้อยธุรกิจกับเลเยอร์ UI หากผลิตภัณฑ์ของคุณทำสิ่งที่น่าสนใจอย่างอ่อนโยนมันจำเป็นอย่างยิ่งสำหรับการแยกนี้เพื่อเปิดใช้งานการใช้รหัสซ้ำ

ในฐานะนักพัฒนา C # ฉันไม่คิดว่าคุณจะเป็นคนเจ้าชู้ในการทำงานภายนอก ฉันชอบทำแบบจำลองโดเมนก่อนจริง ๆ แล้ว

สำหรับ WPF ข้อเสียเพียงอย่างเดียวของแบบจำลองที่ฉันอธิบายนั่นคือบางครั้งคุณต้องเป็นสื่อกลางระหว่าง UI และแบบจำลองโดเมนของคุณ ถึงกระนั้นบางครั้งก็หมายถึงการทำงานที่มากขึ้น แต่ก็หมายถึงรหัสที่สะอาดกว่า

แน่นอนว่าโดเมนเป็นอันดับแรก!

ความสวยงามของ Smalltalk คือคุณสามารถ "ขับเคลื่อน" โมเดลโดเมนได้อย่างง่ายดายในหลาย ๆ ด้านรวมถึงการทำ "พิมพ์" จากพื้นที่ทำงานหรือผู้ตรวจสอบ เฉพาะเมื่อคุณแน่ใจว่าโดเมนของคุณทำงานได้ตามที่ต้องการคุณไม่กล้ามุ่งเน้นการสร้าง GUI ที่สมบูรณ์แบบ

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