จุดประสงค์ของการใช้ DTO คืออะไร (Data Transfer Objects)?

132

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

java design-patterns

— Vinoth Kumar CM
แหล่งที่มา

10

แต่ POJO สามารถเป็น DTO และ DTO สามารถนำไปใช้กับ POJO ได้ คุณกำลังเปรียบเทียบแอปเปิ้ลและส้ม

— สุข

3

ทำไมความคิดที่ดีควรล้าสมัย? ดูเสียงกระเพื่อม นอกจากเรื่องตลกฉันเห็นด้วยกับ Euphoric: ปกติฉันจะใช้ DTO โดยใช้ POJO ฉันยังพบว่า DTO นั้นง่ายมาก (KISS) และมีแนวคิดที่เป็นประโยชน์

— Giorgio

ไม่มีจุดมันเป็นรูปแบบการต่อต้านดู: วัตถุการถ่ายโอนข้อมูลเป็นความอัปยศ

— yegor256

115

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

DTO เป็นแนวคิดพื้นฐานไม่ใช่ล้าสมัย

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

9

คุณอาจพบว่าพวกเขาภายใต้ชื่อที่แตกต่างกัน แต่เนื่องจากทุกคนน่าจะ reinventing ล้อวันนี้

— linkerro

3

เช่น "วัตถุค่า"

— theD

2

@linkerro: จริง: ฉันคิดว่าผู้คนจำนวนมากควรใช้เวลามากขึ้นในการอ่านเกี่ยวกับสิ่งที่ถูกประดิษฐ์ขึ้นมาแล้วแทนที่จะประดิษฐ์มันขึ้นมาใหม่ สิ่งที่ถูกคิดค้นขึ้นใหม่จะมีความเป็นผู้ใหญ่น้อยลง

— Giorgio

10

@Giorgio มีผู้พัฒนาจำนวนมากที่ยังคงวิ่งไปพร้อมกับความคิดที่ไม่ควรทำให้หลุดโลก ฉันหวังว่า devs มากขึ้นจะถามทุกความคิดที่พวกเขาอ่าน

— Erik Reppen

59

DTO เป็นแนวคิด (วัตถุที่มีวัตถุประสงค์เพื่อรวบรวมข้อมูลเพื่อส่งคืนไปยังไคลเอนต์โดยเซิร์ฟเวอร์) จะไม่ล้าสมัยอย่างแน่นอน

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

อย่างไรก็ตามเหตุผลที่ความคิดนี้ล้าสมัยมากกว่าแค่ความผิดปกติก็คือเฟรมเวิร์ก / เทคโนโลยี (ส่วนใหญ่มีอายุมากกว่า) ต้องการเพราะโดเมนและมุมมองโมเดลของพวกเขาไม่ใช่ POJOS และแทนที่จะเชื่อมโยงโดยตรงกับเฟรมเวิร์ก

โดยเฉพาะอย่างยิ่ง Entity Beans ใน J2EE ก่อนมาตรฐาน EJB 3 ไม่ใช่ POJOs และเป็นวัตถุพร็อกซีที่สร้างขึ้นโดยเซิร์ฟเวอร์แอปแทนที่จะเป็นไปไม่ได้ที่จะส่งไปยังลูกค้าดังนั้นคุณจึงไม่มีทางเลือกเกี่ยวกับชั้น DTO แยก - มันเป็นข้อบังคับ

— Michael Borgwardt
แหล่งที่มา

2

ในฐานะที่เป็น UI dev ถูกบังคับให้มีบทบาทที่กว้างขึ้นฉันได้พบปรากฏการณ์ Mapper.Map ใน codebase ของเราอย่างน่าประหลาดใจ เหตุใด DTO จึงไม่สามารถแมปตัวเองได้

— Erik Reppen

1

@ErikReppen ประโยชน์หลักคือการแยกโมเดลโดเมนของคุณ & ของ DTO หาก DTO ของคุณจับคู่ตัวเองมันต้องมีการอ้างอิงถึงโมเดลโดเมนของคุณ

— Alexander Derck

17

แม้ว่า DTO ไม่ใช่รูปแบบที่ล้าสมัย แต่มักใช้โดยไม่จำเป็นซึ่งอาจทำให้ดูเก่าเกินไป

รูปแบบที่ใช้ในทางที่ผิดมากที่สุดในชุมชน Java Enterprise คือ DTO DTO นั้นถูกกำหนดไว้อย่างชัดเจนว่าเป็นทางออกสำหรับปัญหาการแจกจ่าย DTO หมายถึงเป็นที่เก็บข้อมูลแบบหยาบซึ่งมีประสิทธิภาพในการขนส่งข้อมูลระหว่างกระบวนการ (ชั้น) ~ อดัมเบียน

ตัวอย่างเช่นสมมติว่าคุณมี JSF ManagedBean คำถามที่พบบ่อยคือถั่วควรเก็บการอ้างอิงถึง JPA Entity โดยตรงหรือควรรักษาการอ้างอิงไปยังวัตถุตัวกลางบางอย่างซึ่งจะถูกแปลงเป็น Entity ในภายหลัง ฉันเคยได้ยินวัตถุตัวกลางนี้เรียกว่า DTO แต่ถ้า ManagedBeans และเอนทิตีของคุณทำงานภายใน JVM เดียวกันก็มีประโยชน์เล็กน้อยในการใช้รูปแบบ DTO

พิจารณาคำอธิบายประกอบ Bean Validation หน่วยงาน JPA ของคุณมีแนวโน้มที่จะมีคำอธิบายประกอบด้วยการตรวจสอบ @NotNull และ @Size หากคุณใช้ DTO คุณจะต้องทำการตรวจสอบความถูกต้องเหล่านี้ซ้ำใน DTO ของคุณเพื่อให้ลูกค้าที่ใช้อินเทอร์เฟซระยะไกลของคุณไม่จำเป็นต้องส่งข้อความเพื่อตรวจสอบว่าพวกเขาล้มเหลวในการตรวจสอบเบื้องต้น ลองจินตนาการว่างานพิเศษทั้งหมดของการคัดลอกคำอธิบายประกอบ Bean Validation ระหว่าง DTO และ Entity ของคุณ แต่ถ้ามุมมองและเอนทิตีของคุณทำงานภายใน JVM เดียวกันคุณไม่จำเป็นต้องใช้งานพิเศษนี้เพียงแค่ใช้เอนทิตี

ลิงก์ของ IAmTheDude ไปยังแคตตาล็อกของรูปแบบของสถาปัตยกรรมแอปพลิเคชันองค์กรให้คำอธิบายที่กระชับของ DTOs และนี่คือการอ้างอิงเพิ่มเติมที่ฉันพบว่าให้ความกระจ่าง:

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

3

มีประโยคคือ: "... แต่ถ้า ManagedBeans และหน่วยงานของคุณมีการดำเนินงานภายใน JVM เดียวกันแล้วมีผลประโยชน์เล็ก ๆ น้อย ๆ จากการใช้รูปแบบ DTO" มีแอพพลิเคชั่นขนาดกลางจำนวนมากใน บริษัท ที่เปิดใช้งานรูปแบบ DTO อย่างโง่เขลาโดยไม่ได้รับประโยชน์ใด ๆ มันเพิ่งเพิ่ม "เลเยอร์การคัดลอก" ที่ไร้ประโยชน์ คนที่สร้างระบบเหล่านี้ไม่ทราบว่า Java EE 5+ entity manager แยกเอนทิตี้เมื่อธุรกรรมสิ้นสุดและทำให้พวกเขาเป็น DTO จริง ดังนั้นสำหรับ webapps เดียว JVM รูปแบบชนิดของล้าสมัย มันน่าจะเป็นของที่ระลึกนักพัฒนา J2EE แบ็กเอนด์ ...

— Kawu

แต่ "JSF ManagedBean" และ "JPA Entity" คืออะไร หากพวกเขาไม่ล้าสมัยคุณควรจะสามารถอธิบายได้โดยใช้กรอบและคำที่ไม่เชื่อเรื่องภาษา

— U Avalos

8

ไม่ได้อย่างแน่นอน! เมื่อเร็ว ๆ นี้ฉันได้เรียนรู้บทเรียนเกี่ยวกับการใช้ DTO ที่ดีกว่าการใช้วัตถุทางธุรกิจของคุณ (อาจผูกมัดกับผู้ทำแผนที่ ORM)

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

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

1

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

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