วัตถุ CLR แบบเก่าธรรมดากับวัตถุการถ่ายโอนข้อมูล

POCO = วัตถุ CLR แบบเก่า (หรือดีกว่า: คลาส)

DTO = วัตถุการถ่ายโอนข้อมูล

ในโพสต์นี้มีความแตกต่าง แต่บล็อกที่ฉันอ่านส่วนใหญ่อธิบาย POCO ตามวิธีที่ DTO กำหนดไว้: DTO เป็นคอนเทนเนอร์ข้อมูลแบบง่ายที่ใช้สำหรับย้ายข้อมูลระหว่างเลเยอร์ของแอปพลิเคชัน

POCO และ DTO เหมือนกันหรือไม่

POCO เป็นไปตามกฎของ OOP ควร (แต่ไม่จำเป็นต้อง) มีสถานะและพฤติกรรม POCO มาจาก POJO ประกาศเกียรติคุณโดย Martin Fowler [ เรื่องเล็ก ๆ น้อย ๆ ที่นี่ ] เขาใช้คำว่า POJO เป็นวิธีที่จะทำให้มันดูเซ็กซี่ขึ้นกว่าที่จะปฏิเสธการใช้งาน EJB อย่างหนัก POCO ควรใช้ในบริบทเดียวกันใน. Net อย่าปล่อยให้กรอบกำหนดการออกแบบวัตถุของคุณ

จุดประสงค์เดียวของ DTO คือการถ่ายโอนสถานะและไม่ควรมีพฤติกรรมใด ๆ ดูคำอธิบายของ Martin Fowler เกี่ยวกับ DTOสำหรับตัวอย่างของการใช้รูปแบบนี้

นี่คือความแตกต่าง: POCO อธิบายวิธีการเขียนโปรแกรม ( การเขียนโปรแกรมเชิงวัตถุแบบเก่าที่ดี) ซึ่งDTO เป็นรูปแบบที่ใช้ในการ "ถ่ายโอนข้อมูล" โดยใช้วัตถุ

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

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

มันอาจจะซ้ำซ้อนสำหรับฉันที่จะมีส่วนร่วมเนื่องจากฉันได้ระบุตำแหน่งของฉันในบทความบล็อกของฉันแล้ว แต่ย่อหน้าสุดท้ายของบทความนั้นสรุป:

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

BTW, Patrick ฉันอ่าน POCO เป็นบทความ Lifestyle และฉันเห็นด้วยอย่างยิ่งว่าเป็นบทความที่ยอดเยี่ยม ที่จริงแล้วเป็นส่วนหนึ่งของหนังสือ Jimmy Nilsson ที่ฉันแนะนำ ฉันไม่ทราบว่ามันมีให้ทางออนไลน์ หนังสือของเขาเป็นแหล่งข้อมูลที่ดีที่สุดที่ฉันพบใน POCO / DTO / Repository / และแนวทางการพัฒนา DDD อื่น ๆ

POCO เป็นเพียงวัตถุที่ไม่พึ่งพากรอบภายนอก มันเป็นธรรมดา

ไม่ว่า POCO จะมีพฤติกรรมหรือไม่ก็ตาม

DTO อาจเป็น POCO เช่นเดียวกับวัตถุโดเมน (ซึ่งโดยทั่วไปจะอุดมไปด้วยพฤติกรรม)

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

ในสถาปัตยกรรมสไตล์ Onion ทั่วไป (มักใช้ภายในวิธี DDD แบบกว้าง ๆ ) เลเยอร์โดเมนจะถูกวางไว้ที่กึ่งกลางดังนั้นวัตถุของมันไม่ควรที่จุดนี้จะมีการพึ่งพานอกเลเยอร์นั้น

ฉันเขียนบทความสำหรับหัวข้อนั้น: DTO กับ Value Object กับ POCOPOCO

ในระยะสั้น:

• DTO! = วัตถุค่า
• DTO ⊂ POCO
• วัตถุค่า⊂ POCO

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

ตัวอย่างหนึ่งที่ POCO เป็นสิ่งที่แตกต่างจาก DTO คือเมื่อคุณกำลังพูดถึง POCO ภายในโมเดลโดเมน / โมเดลธุรกิจเชิงตรรกะซึ่งเป็นตัวแทน OO ที่ดีของโดเมนปัญหาของคุณ คุณสามารถใช้ POCO ได้ตลอดทั้งแอปพลิเคชัน แต่สิ่งนี้อาจมีผลข้างเคียงที่ไม่พึงประสงค์บางประการเช่นการรั่วไหลของความรู้ DTO นั้นเป็นอินสแตนซ์ที่ใช้จาก Service Layer ซึ่ง UI สื่อสารกับ, DTO นั้นเป็นการนำเสนอข้อมูลแบบแบนและใช้สำหรับให้ข้อมูลกับ UI และสื่อสารการเปลี่ยนแปลงกลับไปยังเลเยอร์บริการ เซอร์วิสเลเยอร์รับผิดชอบการแมป DTO ทั้งสองวิธีกับวัตถุโดเมน POCO

ปรับปรุง Martin Fowler กล่าวว่าวิธีการนี้เป็นเส้นทางที่ต้องใช้งานมากและควรดำเนินการเฉพาะในกรณีที่มีความไม่ตรงกันอย่างมากระหว่างชั้นโดเมนและส่วนติดต่อผู้ใช้

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

นี่คือกฎทั่วไป: DTO == ความชั่วร้ายและตัวบ่งชี้ของซอฟต์แวร์ที่มีการออกแบบเกิน POCO == ดี รูปแบบ 'องค์กร' ได้ทำลายสมองของผู้คนจำนวนมากในโลก Java EE โปรดอย่าทำผิดซ้ำอีกในที่ดิน. NET

คลาส DTO ใช้ในการซีเรียลไลซ์ / ดีซีเรียลไลซ์ข้อมูลจากแหล่งต่าง ๆ เมื่อคุณต้องการแยกแยะวัตถุจากแหล่งที่มาไม่สำคัญว่าจะเป็นแหล่งข้อมูลภายนอกใด: บริการไฟล์ฐานข้อมูล ฯลฯ คุณอาจต้องการใช้เพียงบางส่วนเท่านั้น แต่คุณต้องการวิธีที่ง่ายในการจัดลำดับข้อมูลให้กับ วัตถุ. หลังจากนั้นคุณคัดลอกข้อมูลนั้นไปยัง XModel ที่คุณต้องการใช้ Serializer เป็นเทคโนโลยีที่สวยงามในการโหลดวัตถุ DTO ทำไม? คุณต้องการเพียงหนึ่งฟังก์ชั่นในการโหลด (ดีซีเรียลไลซ์) วัตถุ

TL; DR:

DTO อธิบายถึงรูปแบบของการถ่ายโอนสถานะ POCO ไม่ได้อธิบายอะไรเลย เป็นอีกวิธีหนึ่งในการพูดว่า "object" ใน OOP มันมาจาก POJO (Java) ประกาศเกียรติคุณจาก Martin Fowler ผู้อธิบายเพียงแค่ว่ามันเป็นชื่อที่นักเล่น 'วัตถุ' เพราะ 'วัตถุ' ไม่ได้เซ็กซี่มาก

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

POCO เป็นวัตถุธรรมดา แต่สิ่งที่มีความหมายโดย 'ธรรมดา' คือมันไม่พิเศษ มันหมายความว่ามันเป็นวัตถุ CLR ที่ไม่มีรูปแบบโดยนัย ศัพท์ทั่วไป มันไม่ได้ทำงานกับกรอบอื่น ๆ ดังนั้นถ้า POCO ของคุณมี[JsonProperty]หรือ EF ตกแต่งอยู่ทั่วทุกแห่งมันก็เป็นคุณสมบัติเช่นกันดังนั้นฉันจะยืนยันว่าไม่ใช่ POCO

นี่คือตัวอย่างของรูปแบบวัตถุชนิดต่าง ๆ เพื่อเปรียบเทียบ:

• ดูโมเดล : ใช้เพื่อสร้างโมเดลข้อมูลสำหรับมุมมอง มักจะมีคำอธิบายประกอบข้อมูลเพื่อช่วยในการผูกและการตรวจสอบ ใน MVVM มันยังทำหน้าที่เป็นตัวควบคุม มันเป็นมากกว่า DTO
• วัตถุค่า : ใช้เพื่อแสดงค่า
• Aggregate Root : ใช้เพื่อจัดการสถานะและค่าคงที่
• ตัวจัดการ : ใช้เพื่อตอบกลับเหตุการณ์ / ข้อความ
• คุณสมบัติ : ใช้เป็นของประดับตกแต่งเพื่อจัดการกับข้อกังวลข้าม
• บริการ : ใช้เพื่อทำงานที่ซับซ้อน
• Controller : ใช้สำหรับควบคุมการไหลของคำร้องขอและการตอบกลับ
• Factory : ใช้เพื่อกำหนดค่าและ / หรือรวบรวมวัตถุที่ซับซ้อนเพื่อใช้เมื่อตัวสร้างไม่ดีพอ นอกจากนี้ยังใช้ในการตัดสินใจว่าจะต้องสร้างวัตถุใดในรันไทม์
• Repository / DAO : ใช้เพื่อเข้าถึงข้อมูล

สิ่งเหล่านี้ล้วนเป็นแค่วัตถุ แต่สังเกตว่าส่วนใหญ่มักจะเชื่อมโยงกับลวดลาย ดังนั้นคุณสามารถเรียกพวกเขาว่า "วัตถุ" หรือคุณอาจเจาะจงเจาะจงมากขึ้นเกี่ยวกับเจตนาของมันและเรียกมันตามสิ่งที่มันเป็น นี่คือสาเหตุที่เรามีรูปแบบการออกแบบ เพื่ออธิบายแนวคิดที่ซับซ้อนในงานไม่กี่ DTO เป็นรูปแบบ รูทรวมเป็นรูปแบบ View Model เป็นรูปแบบ (เช่น MVC & MVVM) POCO ไม่ใช่รูปแบบ

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

• DTO คือ POCO
• POCO ไม่ใช่ DTO
• รูปแบบการดูเป็น POCO
• POCO ไม่ใช่ View Model

ประเด็นในการสร้างความแตกต่างระหว่างทั้งสองคือการรักษารูปแบบที่ชัดเจนและสอดคล้องกันในความพยายามที่จะไม่ข้ามความกังวลและนำไปสู่การมีเพศสัมพันธ์แน่น ตัวอย่างเช่นถ้าคุณมีออบเจ็กต์ธุรกิจที่มีวิธีการเปลี่ยนแปลงสถานะ แต่ตกแต่งด้วยนรกด้วยการตกแต่งของ EF สำหรับการบันทึกไปยัง SQL Server และ JsonProperty เพื่อให้สามารถส่งกลับไปยังจุดปลายทาง API ได้ วัตถุนั้นจะทนต่อการเปลี่ยนแปลงและมีแนวโน้มว่าจะถูกทิ้งให้เกลื่อนไปด้วยคุณสมบัติต่างๆ (เช่น UserId, UserPk, UserKey, UserGuid, ที่บางคนถูกทำเครื่องหมายว่าไม่ถูกบันทึกลงในฐานข้อมูลและอื่น ๆ ที่ทำเครื่องหมายว่าไม่ JSON ที่จุดสิ้นสุด API)

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

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

ฉันหวังว่าคำศัพท์โง่ ๆ จะหายไปจากคำศัพท์ของเรา