รูปแบบเพื่อแบ่งปันวัตถุระหว่าง API และแอปพลิเคชัน

ฉันมีข้อสงสัยอย่างมากเกี่ยวกับการออกแบบสำหรับเว็บแอปพลิเคชันของฉัน

ฉันต้องการแยกตรรกะทางธุรกิจออกจากส่วนติดต่อดังนั้นฉันจึงสร้าง Web API ที่จัดการคำขอทั้งหมดไปยังฐานข้อมูล

มันเป็น ASP.NET Web API พร้อม Entity framework และหน่วยการทำงานและรูปแบบพื้นที่เก็บข้อมูลทั่วไป จนถึงตอนนี้ทุกอย่างดี

ปัญหา

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

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

วิธีการใช้งานตอนนี้

เนื่องจากอินเทอร์เฟซของฉันคือ ASP.NET เว็บแอปพลิเคชันใน C # และ API ของฉันอยู่ใน C # ฉันจึงสร้างไลบรารีทั่วไปพร้อมคำจำกัดความของคลาสทั้งหมดของฉันที่ฉันต้องการแชร์ระหว่างพวกเขา

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

ปัญหาคือฉันรู้สึกว่าฉันมักจะแปลงวัตถุของฉัน

ตัวอย่าง

นี่คือตัวอย่างของกระบวนการทำงานของฉัน:

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

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

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

ดังนั้นฉันมี 3 ชั้น

1. โมเดลสำหรับมุมมองพร้อมหมายเหตุประกอบข้อมูลทั้งหมดสำหรับการตรวจสอบความถูกต้อง (ไคลเอ็นต์)
2. คลาสไลบรารีทั่วไปเพื่อแชร์วัตถุ (DLL)
3. คลาสเอนทิตี (API)

ฉันรู้สึกว่าฉันทำอะไรผิดไปจริงๆ มีบางสิ่งที่หรูหรากว่านี้ไหม? ฉันต้องการให้แน่ใจว่าฉันมีทางออกที่ดีสำหรับปัญหานี้ก่อนที่โครงการจะใหญ่เกินไป

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

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

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

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

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

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

• ใช้ไลบรารีที่ใช้ประโยชน์จากการแปลงวัตถุเป็นส่วนใหญ่ยกตัวอย่างเช่นถ้าคุณใช้ C # คุณสามารถใช้ไลบรารี่ AutoMapper ที่ยอดเยี่ยม ( http://automapper.org/ ) ฉันเชื่อว่ามีห้องสมุดอื่นสองสามแห่งเช่นนี้ แต่ AutoMapper เป็นห้องสมุดที่ทรงพลังที่สุดเท่าที่ฉันเคยเห็นมา
• หากคุณไม่พบห้องสมุดที่ช่วยคุณแปลงวัตถุให้เขียนชุดของวิธีการอรรถประโยชน์สำหรับการแปลงระหว่างกัน สิ่งนี้อาจดูด แต่ก็คุ้มค่าในระยะยาวเขียนวิธีการแปลงในครั้งแรกที่คุณต้องการแปลงบางสิ่ง - ไม่ต้องรอ