ทำไมส่งคืนวัตถุแทนอาร์เรย์

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

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

ฉันเป็นโปรแกรมเมอร์ PHP ที่เรียนรู้ด้วยตนเอง ฉันได้รับปริญญาศิลปศาสตร์ ดังนั้นโปรดยกโทษให้ฉันหากฉันพลาดแง่มุมพื้นฐานของวิทยาศาสตร์คอมพิวเตอร์ ;)

นี่คือสาเหตุที่ฉันชอบวัตถุโดยทั่วไป:

• ออบเจ็กต์ไม่เพียง แต่มีข้อมูลเท่านั้น แต่ยังมีฟังก์ชันการทำงานอีกด้วย
• ออบเจ็กต์มีโครงสร้างที่กำหนดไว้ล่วงหน้า (ในกรณีส่วนใหญ่) สิ่งนี้มีประโยชน์มากสำหรับการออกแบบ API นอกจากนี้คุณสามารถตั้งค่าคุณสมบัติเป็นสาธารณะป้องกันหรือส่วนตัวได้
• วัตถุเหมาะสมกับการพัฒนาเชิงวัตถุ
• ในการเติมข้อความอัตโนมัติของ IDE ส่วนใหญ่จะใช้ได้กับออบเจ็กต์เท่านั้น

นี่คือสิ่งที่ต้องอ่าน:

• วัตถุเทียบกับ Array ใน PHP
• PHP stdClass: การจัดเก็บข้อมูลใน Object แทนที่จะเป็น Array
• ฉันควรใช้ stdClass เมื่อใดและฉันควรใช้อาร์เรย์ในโค้ด php5 oo เมื่อใด
• PHP Objects เทียบกับ Arrays
• ผลลัพธ์ Mysql ใน PHP - อาร์เรย์หรือวัตถุ?
• วัตถุ PHP เทียบกับตำนานประสิทธิภาพอาร์เรย์
• ชุดของวัตถุใน PHP: Arrays กับ SplObjectStorage
• อาร์เรย์เชิงวัตถุที่ดีกว่า

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

มาดูตัวอย่างกัน

• หากอาร์เรย์ถูกส่งกลับค่าทั้งหมดจะต้องถูกคำนวณล่วงหน้าหรือต้องส่งคืนค่าเล็กน้อยจำนวนมากซึ่งคุณสามารถสร้างค่าที่ซับซ้อนขึ้นได้

ลองนึกถึงวิธี API ที่แสดงรายการโพสต์ WordPress โพสต์เหล่านี้ล้วนมีผู้แต่งผู้แต่งมีชื่อที่อยู่อีเมลหรือแม้แต่โปรไฟล์ที่มีชีวประวัติของพวกเขา

หากคุณส่งคืนโพสต์ทั้งหมดในอาร์เรย์คุณอาจต้อง จำกัด ตัวเองในการส่งคืนอาร์เรย์ของรหัสโพสต์:

[233, 41, 204, 111]

หรือส่งคืนอาร์เรย์ขนาดใหญ่ที่มีลักษณะดังนี้:

[ title: 'somePost', body: 'blah blah', 'author': ['name': 'billy', 'email': 'bill@bill.com', 'profile': ['interests': ['interest1', 'interest2', ...], 'bio': 'info...']] ]
[id: '2', .....]]

กรณีแรกของการส่งคืนรายการ ID ไม่เป็นประโยชน์กับคุณมากนักเพราะคุณต้องทำการเรียก API สำหรับแต่ละ ID เพื่อรับข้อมูลบางอย่างเกี่ยวกับโพสต์นั้น

กรณีที่สองจะดึงข้อมูลได้มากกว่าที่คุณต้องการ 90% ของเวลาและทำงานได้มากขึ้น (โดยเฉพาะอย่างยิ่งหากฟิลด์ใด ๆ ที่ซับซ้อนมากในการสร้าง)

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

• อาร์เรย์เปิดเผยข้อมูลและความสามารถมากกว่าที่ตั้งใจไว้

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

• ฟังก์ชันการทำงาน

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

• ความยืดหยุ่น

ประโยชน์ทั้งหมดของออบเจ็กต์ที่กล่าวมาข้างต้นช่วยในการสร้างระบบที่ยืดหยุ่นมากขึ้น

คำถามของฉันคือทำไมพวกเขาใช้วัตถุแทนอาร์เรย์

อาจเป็นสองเหตุผล:

• WordPress ค่อนข้างเก่า
• อาร์เรย์เร็วกว่าและใช้หน่วยความจำน้อยกว่าในกรณีส่วนใหญ่
• ต่ออนุกรมได้ง่ายขึ้น

มีเหตุผลด้านประสิทธิภาพในการใช้วัตถุหรือไม่?

ไม่ แต่มีเหตุผลอื่น ๆ อีกมากมายที่ดีเช่น:

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

OOP ! = AOP :)

(ตัวอย่างเช่นใน Ruby ทุกอย่างเป็นออบเจ็กต์ PHP เป็นภาษาขั้นตอน / สคริปต์ก่อนหน้านี้)

WordPress (และแอพพลิเคชั่น PHP อื่น ๆ ในปริมาณพอสมควร) ใช้อ็อบเจกต์มากกว่าอาร์เรย์เพื่อแนวคิดมากกว่าเหตุผลทางเทคนิค

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

ในอดีต PHP ไม่ได้รองรับวัตถุที่ดีเยี่ยมดังนั้นอาร์เรย์จึงมีประสิทธิภาพมากในช่วงแรก ๆ (ตัวอย่างเช่นความสามารถในการมีคีย์โดยพลการแทนที่จะเป็นศูนย์) ด้วยการสนับสนุนอ็อบเจ็กต์ที่มีอยู่ใน PHP 5 ตอนนี้นักพัฒนามีทางเลือกระหว่างการใช้อาร์เรย์หรืออ็อบเจกต์เป็นที่เก็บคีย์ - ค่า โดยส่วนตัวแล้วฉันชอบแนวทาง WordPress มากกว่าเพราะฉันชอบความแตกต่างทางวากยสัมพันธ์ระหว่าง 'เอนทิตี' และ 'คอลเลกชัน' ที่อ็อบเจ็กต์และอาร์เรย์มีให้

คำถามของฉันคือทำไมพวกเขา (Wordpress) ใช้วัตถุแทนอาร์เรย์

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

น้ำตาลวากยสัมพันธ์สำหรับอาร์เรย์ที่เชื่อมโยง - Zeev Suraski เกี่ยวกับวัตถุมาตรฐานตั้งแต่ PHP 3

• stdClassออบเจ็กต์ไม่ได้ดีไปกว่าอาร์เรย์จริงๆ พวกเขาค่อนข้างเหมือนกัน นั่นเป็นเพราะเหตุผลทางประวัติศาสตร์บางประการของภาษาเช่นเดียวกับstdClassวัตถุมีข้อ จำกัด และจริงๆแล้วเป็นเพียงวัตถุที่มีค่าในความหมายพื้นฐานเท่านั้น
• stdClassออบเจ็กต์เก็บค่าสำหรับสมาชิกของพวกเขาเช่นเดียวกับอาร์เรย์ต่อรายการ และนั่นแหล่ะ
• มีเพียง PHP freaks เท่านั้นที่สามารถสร้างstdClassวัตถุด้วยสมาชิกส่วนตัวได้ ไม่มีประโยชน์มากนักหากมี - การทำเช่นนั้น
• stdClassออบเจ็กต์ไม่มีเมธอด / ฟังก์ชันใด ๆ ดังนั้นอย่าใช้สิ่งนั้นใน Wordpress
• เมื่อเทียบกับarrayแล้วมีฟังก์ชันที่เป็นประโยชน์น้อยกว่ามากในการจัดการกับรายการหรือข้อมูลกึ่งโครงสร้าง

อย่างไรก็ตามหากคุณคุ้นเคยกับอาร์เรย์เพียงแค่ส่ง:

$array = (array) $object;

และคุณสามารถเข้าถึงข้อมูลก่อนหน้านี้ที่เป็นวัตถุเป็นอาร์เรย์ หรือคุณชอบในทางกลับกัน:

$object = (object) $array;

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

ที่เกี่ยวข้อง:

• การแปลงเป็นวัตถุ^{PHP Manual}
• ^{คู่มือ PHP สำหรับ}คลาสที่สงวนไว้
• stdClass ใน PHP คืออะไร?

1. โค้ดดูเท่กว่านั้น
2. วัตถุผ่านการอ้างอิง
3. อ็อบเจ็กต์มีการพิมพ์ที่รัดกุมกว่าจากนั้นอาร์เรย์จึงทำให้เกิดข้อผิดพลาด (หรือให้ข้อความแสดงข้อผิดพลาดที่มีความหมายเมื่อคุณพยายามใช้สมาชิกที่ไม่มีอยู่)
4. IDE ทั้งหมดในปัจจุบันมีการเติมข้อความอัตโนมัติดังนั้นเมื่อทำงานกับออบเจ็กต์ที่กำหนดไว้ IDE จะทำสิ่งต่างๆให้คุณได้มากและเร็วขึ้น
5. Easilly ห่อหุ้มลอจิกและข้อมูลไว้ในกล่องเดียวกันโดยที่อาร์เรย์จะเก็บข้อมูลไว้ในอาร์เรย์จากนั้นใช้ชุดของฟังก์ชันที่แตกต่างกันเพื่อประมวลผล
6. การถ่ายทอดทางพันธุกรรมหากคุณมีอาร์เรย์ที่คล้ายกันซึ่งมีฟังก์ชันการทำงานที่เกือบจะเหมือนกัน แต่ไม่เหมือนกันคุณจะต้องทำโค้ดซ้ำมากขึ้นถ้าคุณจะทำกับวัตถุ

อาจมีเหตุผลมากกว่านี้ที่ฉันคิดไว้

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

นอกจากนี้คุณควรพิจารณาหลักการ OO ของการซ่อนข้อมูล ไม่ใช่ทุกสิ่งที่กลับมาจากหรือไปที่ฐานข้อมูลควรสามารถเข้าถึงได้โดยตรง

มีสาเหตุหลายประการในการส่งคืนวัตถุ:

1. การเขียน$myObject->propertyต้องใช้อักขระ "เหนือศีรษะ" น้อยกว่า$myArray['element']

2. วัตถุสามารถส่งคืนข้อมูลและการทำงาน อาร์เรย์สามารถมีได้เฉพาะข้อมูล

3. เปิดใช้งานการเชื่อมโยง: $myobject->getData()->parseData()->toXML();

4. การเข้ารหัสที่ง่ายขึ้น: การเติมข้อความอัตโนมัติ IDE สามารถให้คำแนะนำวิธีการและคุณสมบัติสำหรับวัตถุ

ในแง่ของประสิทธิภาพอาร์เรย์มักจะเร็วกว่าวัตถุ นอกจากประสิทธิภาพแล้วยังมีเหตุผลอีกหลายประการในการใช้อาร์เรย์:

1. ฟังก์ชันการทำงานที่จัดเตรียมโดยกลุ่มฟังก์ชันอาร์เรย์ _ * () สามารถลดจำนวนการเข้ารหัสที่จำเป็นในบางกรณีได้

2. การดำเนินการเช่น count () และ foreach () สามารถทำได้บนอาร์เรย์ ออบเจ็กต์ไม่เสนอสิ่งนี้ (เว้นแต่จะใช้IteratorหรือCountable )

โดยปกติจะไม่เป็นเพราะเหตุผลด้านประสิทธิภาพ โดยปกติออบเจ็กต์มีราคามากกว่าอาร์เรย์

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

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

$obj = new MyObject;
$obj->getName();   // this calls a method (function), so it can decide what to return based on conditions or other criteria

$array['name'];   // this is just the string "name". there is no logic to it. 

บางครั้งคุณกำลังเข้าถึงตัวแปรออบเจ็กต์โดยตรงซึ่งมักจะขมวดคิ้ว แต่มันก็เกิดขึ้นบ่อยครั้ง

$obj->name;   // accessing the string "name" ... not really different from an array in this case.

อย่างไรก็ตามโปรดพิจารณาว่าคลาส MyObject ไม่มีตัวแปรที่เรียกว่า 'name' แต่มีตัวแปร first_name และ last_name แทน

$obj->getName();  // this would return first_name and last_name joined.
$obj->name;  // would fail...
$obj->first_name; 
$obj->last_name; // would be accessing the variables of that object directly.

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

วัตถุเวลาส่วนใหญ่จะเร็วพอ ๆ กันถ้าไม่เร็วกว่าอาร์เรย์ใน PHP ไม่มีความแตกต่างที่เห็นได้ชัดเจน สาเหตุหลักคือวัตถุมีพลังมากกว่าอาร์เรย์ การเขียนโปรแกรมเชิงวัตถุช่วยให้คุณสามารถสร้างออบเจ็กต์และจัดเก็บข้อมูลไม่เพียงเท่านั้น แต่ยังมีฟังก์ชันการทำงานอยู่ในนั้นด้วยตัวอย่างเช่นใน PHP MySQLi Class ช่วยให้คุณมีวัตถุฐานข้อมูลที่คุณสามารถจัดการได้โดยใช้โฮสต์ของฟังก์ชัน inbuilt แทนที่จะเป็นวิธีการขั้นตอน

ดังนั้นเหตุผลหลักคือ OOP เป็นกระบวนทัศน์ที่ยอดเยี่ยม ฉันเขียนบทความเกี่ยวกับสาเหตุที่การใช้ OOP เป็นความคิดที่ดีและอธิบายแนวคิดคุณสามารถดูได้ที่นี่: http://tomsbigbox.com/an-introduction-to-oop/

ในฐานะผู้เยาว์บวกคุณพิมพ์น้อยลงเพื่อรับข้อมูลจากออบเจ็กต์ด้วย - $ test-> data นั้นดีกว่า $ test ['data']

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

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

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

ฉันกำลังทำการทดสอบถัดไปใน php 5.3.10 (windows):

for ($i = 0; $i < 1000000; $i++) {
    $x = array();
    $x['a'] = 'a';
    $x['b'] = 'b';
}

และ

for ($i = 0; $i < 1000000; $i++) {
    $x = new stdClass;
    $x->a = 'a';
    $x->b = 'b';
}

คัดลอกมาจาก http://atomized.org/2009/02/really-damn-slow-a-look-at-php-objects/comment-page-1/#comment-186961

เรียกใช้ฟังก์ชันสำหรับผู้ใช้พร้อมกัน 10 คนและ 10 ครั้ง (เพื่อให้ได้ค่าเฉลี่ย) แล้ว

• อาร์เรย์: 100%
• วัตถุ: 214% - 216% (ช้ากว่า 2 เท่า)

AKA วัตถุมันยังคงเจ็บปวดอย่างช้าๆ OOP จัดเก็บสิ่งของให้เป็นระเบียบเรียบร้อยอย่างไรก็ตามควรใช้อย่างระมัดระวัง

Wordpress ใช้อะไร? ทั้งสองวิธีแก้ปัญหาคือการใช้วัตถุอาร์เรย์และวัตถุและอาร์เรย์ Class wpdbใช้ในภายหลัง (และเป็นหัวใจของ Wordpress)

เป็นไปตามหลักการชกมวยและการแกะกล่องของ OOP ในขณะที่ภาษาเช่น Java และ C # รองรับสิ่งนี้ แต่ PHP ไม่รองรับ อย่างไรก็ตามมันสามารถทำได้ในระดับหนึ่งใน PHP เพียง แต่ไม่คมชัดเนื่องจากภาษาเองไม่มีโครงสร้างที่รองรับ การมีประเภทกล่องใน PHP สามารถช่วยในการผูกมัดทำให้ทุกอย่างมุ่งเน้นไปที่วัตถุและอนุญาตให้มีการบอกใบ้ประเภทในลายเซ็นของวิธีการ ข้อเสียคือค่าใช้จ่ายและความจริงที่ว่าตอนนี้คุณมีการตรวจสอบเพิ่มเติมที่ต้องทำโดยใช้โครงสร้าง“instanceof†การมีระบบประเภทยังเป็นข้อดีเมื่อใช้เครื่องมือในการพัฒนาที่มี Intellisense หรือ Code Assist เช่น PDT แทนที่จะต้องใช้ google / bing / yahoo สำหรับวิธีการนี้มีอยู่ในวัตถุและคุณสามารถใช้เครื่องมือเพื่อแสดงรายการแบบเลื่อนลง

แม้ว่าประเด็นที่สร้างขึ้นเกี่ยวกับออบเจ็กต์จะเป็นมากกว่าข้อมูลที่ถูกต้องเนื่องจากโดยปกติแล้วจะเป็นข้อมูลและพฤติกรรม แต่ก็มีอย่างน้อยหนึ่งรูปแบบที่กล่าวถึงใน"Patterns of Enterprise Application Architecture" ของ Martin Fowler ที่ใช้กับฉากประเภทนี้ที่คุณกำลังถ่ายโอน ข้อมูลจากระบบหนึ่ง (แอปพลิเคชันที่อยู่เบื้องหลัง API) และอีกระบบหนึ่ง (แอปพลิเคชันของคุณ)

ของมันวัตถุการถ่ายโอนข้อมูล - วัตถุที่ดำเนินการข้อมูลระหว่างกระบวนการเพื่อลดจำนวนการโทรวิธีการ

ดังนั้นหากคำถามคือว่า API ควรส่งคืน DTO หรืออาร์เรย์หรือไม่ฉันจะบอกว่าหากต้นทุนด้านประสิทธิภาพมีค่าเล็กน้อยคุณควรเลือกตัวเลือกที่บำรุงรักษาได้มากกว่าซึ่งฉันจะโต้แย้งว่าเป็นตัวเลือก DTO ... แต่แน่นอนคุณก็เช่นกัน ต้องพิจารณาทักษะและวัฒนธรรมของทีมที่กำลังพัฒนาระบบของคุณและภาษาหรือ IDE ที่รองรับสำหรับแต่ละตัวเลือก