ORMs เปิดใช้งานการสร้างแบบจำลองโดเมนที่หลากหลายหรือไม่


21

หลังจากใช้ Hibernate ในโครงการส่วนใหญ่ของฉันเป็นเวลาประมาณ 8 ปีฉันได้ตกลงกับ บริษัท ที่ไม่สนับสนุนการใช้งานและต้องการให้แอปพลิเคชันโต้ตอบกับ DB ผ่านขั้นตอนการจัดเก็บเท่านั้น

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

ปัญหาบางอย่างที่ฉันพบคือ:

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

คำถามของฉันคือ:

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

ข้อสรุป

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

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

หากเราใช้ฐานข้อมูลของแอปพลิเคชันเป็นระบบภายนอกเราจำเป็นต้องสร้างนามธรรมที่ช่วยให้เราสามารถแมปเอนทิตีโดเมนโมเดลกับฐานข้อมูล ( ตามที่ NimChimpsky กล่าวถึงโดยใช้ data-mapper) ความแตกต่างที่ชัดเจนคือตอนนี้เราต้องทำการแมปสำหรับแต่ละเอนทิตีโมเดลไปยังฐานข้อมูล (ทั้งสคีมาดั้งเดิมหรือโพรซีเดอร์ที่เก็บไว้) ด้วยความเจ็บปวดพิเศษที่เนื่องจากทั้งสองไม่ซิงค์กันนิติบุคคลโดเมนหนึ่งอาจแมปบางส่วน ไปยังเอนทิตีฐานข้อมูล (เช่นคลาส UserCredentials ที่มีชื่อผู้ใช้และรหัสผ่านเท่านั้นที่ถูกแมปไปยังตารางผู้ใช้ที่มีคอลัมน์อื่น ๆ ) หรือเอนทิตีโมเดลโดเมนหนึ่งอาจจับคู่กับเอนทิตีฐานข้อมูลมากกว่าหนึ่งรายการ (ตัวอย่างเช่น หนึ่งการแมปบนโต๊ะ แต่เราต้องการข้อมูลทั้งหมดในชั้นเดียว)

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

ข้อดีอย่างหนึ่งของการปฏิบัติต่อ DB ในฐานะระบบภายนอกคือเราสามารถเขียนโค้ดสถานการณ์ที่เราต้องการให้แอพพลิเคชั่นทำงานได้ 2 เวอร์ชันซึ่งแต่ละแอพพลิเคชั่นมีการทำแผนที่ที่แตกต่างกัน สิ่งนี้น่าสนใจยิ่งขึ้นในสถานการณ์ของการส่งมอบอย่างต่อเนื่องไปยังการผลิต ... แต่ฉันคิดว่านี่เป็นไปได้ด้วย ORM ในระดับที่น้อยกว่า

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


อัพเดทเล็กน้อย (6/6/2012)

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


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

ดังนั้นฉันจะจบครึ่งแรกของการไฮเบอร์เนตโดยไม่มีประสบการณ์มากกว่า 10 ปีที่ทีมไฮเบอร์เนตมี :)
Augusto

1
DBA ใด ๆ ควรป้องกันการลดลงของตารางเฉพาะโดยผู้ใช้บางราย มันไม่สำคัญว่าคุณจะพยายามทำมันอย่างไร
JeffO

1
คุณอาจดูMybatis - มันอาจให้คุณสมบัติที่คุณต้องการ มันน้อยกว่า ORM กว่ากรอบการทำแผนที่ คุณสามารถเขียน SQL ได้ตามที่คุณต้องการและบอก Mybatis ว่าจะใส่มันไว้ที่ไหนในโมเดลวัตถุของคุณ มันจะจัดการกับกราฟวัตถุขนาดใหญ่ที่มีหลายแบบสอบถามซึ่งดูเหมือนสถานการณ์ที่คุณมี
Michael K

1
@Augusto: ฉันอยู่ในสถานการณ์ที่คล้ายกันไม่ใช่เนื่องจากการใช้ SP แต่เนื่องจากการใช้กรอบการแมปกรรมสิทธิ์ที่ไม่สนับสนุนความสัมพันธ์ของวัตถุ เราใช้เวลาหลายวันในการเขียนโค้ดที่สามารถเขียนเป็นนาทีโดยใช้ ORM ที่เหมาะสม ฉันไม่เคยได้รับการแก้ไขปัญหาที่
วินไคลน์

คำตอบ:


16

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


Martijn ฉันเห็นด้วยว่าแอปควรทำตัวเป็นแบบอย่างโดยใช้หลักการ DDD แต่ปัญหาที่ฉันเผชิญอยู่ (และโปรดบอกฉันว่ามีวิธีแก้ปัญหา !!) หรือไม่นั่นคือวิธีแก้ปัญหา !!) คือ procs ที่เก็บไว้คืนข้อมูลน้อยมาก โปรดดูความคิดเห็นนี้ที่ฉันอธิบายอีกเล็กน้อยเกี่ยวกับข้อมูลที่กระบวนการจัดเก็บกลับมา ฉันสามารถหลีกเลี่ยงสิ่งนี้ได้โดยเรียกใช้ proc ที่จัดเก็บมากกว่าหนึ่งรายการและเช่นดึงข้อมูลรายละเอียดผู้ใช้ทั้งหมดจากนั้นเรียกอีกอันหนึ่งเพื่อเรียกดูข้อมูลบัญชีทั้งหมด แต่รู้สึกผิด :)
Augusto

1
@Augusto เอ่อ ... คุณเป็นผู้พัฒนาแอพดังนั้นคุณต้องตัดสินใจว่ามันมีเหตุผลหรือไม่ที่อ็อบเจกต์บางตัวมีอยู่ในบางฟิลด์ที่ตั้งค่าเป็น NULL ถ้ามันสมเหตุสมผล (สำหรับบางงาน) ให้เป็นเช่นนั้น หากไม่ใช่ให้สอบถามผู้เขียน SP เพื่อให้ข้อมูลเพิ่มเติมเพื่อให้คุณสามารถสร้างวัตถุของคุณ
Jacek Prucia

และเพิ่มความคิดเห็นของ Jacek - จริง ๆ แล้วมันยอมรับได้อย่างสมบูรณ์แบบในการโทร 2+ procs ที่เก็บไว้คิดอีกครั้งว่าพวกเขาเป็นบริการระยะไกลสองอย่างที่คุณต้องโทรเพื่อสร้างโมเดลโดเมนของคุณไม่มีอะไรผิดกับ :-)
Martijn Verburg

@Martijn: จากประสบการณ์ของฉันเลเยอร์บางไม่เพียงพอ รหัสการแมปอาจมีความยาวมากกว่าตรรกะทางธุรกิจพื้นฐาน
kevin cline

@ ไคลน์ไคลน์ - จุดดีได้ใส่ 'หวังว่า' ในคำตอบ :-)
Martijn Verburg

5

มีประโยชน์จริง ๆ ของการใช้กระบวนงานที่เก็บไว้หรือไม่

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


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

1
ฉันทำงานให้กับ บริษัท มหาชนและเราเป็น บริษัท SOX อาจเป็นความรู้ที่ไม่ดีของฉันในการตรวจสอบ แต่ฉันไม่เห็นความแตกต่างระหว่างการตรวจสอบที่ระดับ DB (ผ่าน procs ที่เก็บไว้) หรือที่ระดับแอปพลิเคชัน แต่ละแอปพลิเคชันควรมีสคีมา DB ของตัวเองและสคีมานั้นสามารถเข้าถึงได้จากแอปพลิเคชันเท่านั้นแทนที่จะแชร์ระหว่างแอปพลิเคชันต่างๆ
Augusto

ลิงค์ที่ขาด ...
อเล็กซ์ R

@AlexR ลิงก์ถาวร
Tangurena

2

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

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

ฉันอยู่ในสถานการณ์ที่เราใช้ SP อย่างสมบูรณ์ฐานข้อมูลเป็น API และเราใช้ แอพนั้นมีขนาดใหญ่มากและทำงานได้ดีอย่างน่าอัศจรรย์ ฉันจะไม่พูดอะไรเกี่ยวกับ SP หลังจากนั้น!

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


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

7
SP ไม่จำเป็นต้องมีประสิทธิภาพเสมอไปและฉันคิดว่าการส่ง SQL ไปยัง DBAs นั้นเป็นวิธีที่ไม่ดี ในฐานะผู้เชี่ยวชาญด้านโดเมนผู้พัฒนาควรทราบข้อมูลที่พวกเขาต้องการได้รับและวิธีการรับข้อมูล
Martijn Verburg

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

1
@Augusto the approach of letting the DBAs write the procedures smells like development silos+100 internets ให้คุณสำหรับอัญมณีแห่งความจริงนี้ ฉันมักจะเห็นสิ่งนี้เป็นกรณีที่การเข้าถึงข้อมูลถูกควบคุมผ่านขั้นตอนการจัดเก็บ
maple_shaft

1
@maple_shaft: ทำไม DBA ที่เขียน SPs ไม่ถือว่าเป็นส่วนหนึ่งของทีมนักพัฒนา มันทำงานที่ไหนพวกเขาเป็นผู้เชี่ยวชาญด้านการเขียนโค้ดที่รู้แง่มุมของระบบนี้ดีมากดีกว่านักพัฒนาที่ใช้งานทั่วไป นี่อาจเป็นปัญหาที่ได้รับความนิยมจาก ORM ฉันหมายความว่าไม่มีใครคิดสองครั้งเกี่ยวกับการออกแบบ GUI ทำดังนั้นทำไมความเกลียดชังสำหรับสถาปนิกข้อมูลที่ทำสคีมา
gbjbaanb

2

สิ่งที่มักจะเกิดขึ้นคือผู้พัฒนาใช้วัตถุ ORM ของพวกเขาอย่างไม่ถูกต้องเป็นโมเดลโดเมน

สิ่งนี้ไม่ถูกต้องและเชื่อมโยงโดเมนของคุณกับ DB schema ของคุณโดยตรง

สิ่งที่ควรมีจริงๆคือการแยกโมเดลโดเมนที่หลากหลายตามที่คุณต้องการและใช้เลเยอร์ ORM แยกกัน

ซึ่งหมายความว่าคุณจะต้องทำการแมประหว่างวัตถุแต่ละชุด


1
นี่เป็นความคิดที่ดี แต่สำหรับโครงการขนาดเล็กมันเริ่มรู้สึกเหมือน overkill วิธีนี้ยังต้องการเลเยอร์การแปลระหว่างเลเยอร์การคงอยู่ของ ORM และโมเดลโดเมน
maple_shaft

@maple_shaft เห็นด้วยและนั่นคือสิ่งที่ผมหมายถึง "การทำแผนที่" :-)
Ozz

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

@Augusto ฉันก็ทำได้เช่นกัน! และอย่างที่ maple_shaft บอกว่ามันดีสำหรับแอพสไตล์ CRUD ขนาดเล็ก แต่มีปัญหามากมายที่ OP กำลังค้นหา ตัวอย่างหนึ่งอาจเป็นที่ที่คุณมีตารางการแมปหลายต่อหลายอย่างเช่น: StudentClasses ที่แมปนักเรียนกับชั้นเรียนของพวกเขาและเพียงแค่มี StudentID และ classID คุณไม่จำเป็นต้องแมปนี้ในโดเมนของคุณ นั่นเป็นเพียงตัวอย่างที่รวดเร็วจากหัวตัวอย่างของฉัน
ozz

2
@Ozz: ความคิดเห็นของคุณดูเหมือนจะขัดแย้งกับแนวคิดของ ORM ORM ไม่ได้ "ผูกโดเมนของคุณโดยตรงกับ DB schema ของคุณ" ORM จับคู่โดเมนของคุณกับ DB schema โดยไม่จำเป็นต้องใช้ DAO layer แยกกัน นั่นคือจุดรวมของ ORM และ ORMs ส่วนใหญ่จัดการการแมปหลายต่อหลายได้ดีโดยไม่จำเป็นต้องมีโมเดลโดเมนสำหรับตารางการแมป
วินไคลน์

1

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


ขณะนี้เรากำลังใช้ตัวแมปข้อมูล แต่ปัญหาคือพวกเขาจัดเก็บ procs ส่งคืนชุดข้อมูลที่น้อยที่สุดซึ่งบางครั้งก็ไม่เพียงพอที่จะเติมวัตถุ (บางทีเราควรอนุญาตให้กระบวนการที่เก็บไว้ส่งคืนข้อมูลเพิ่มเติม) ตัวอย่างเช่นหนึ่ง store proc อาจส่งคืนอีเมลผู้ใช้ชื่อผู้ใช้นามสกุล; ในขณะที่อีกอันหนึ่งจะเพิ่มหมายเลขผู้ใช้และที่อยู่ เนื่องจากข้อมูลแตกต่างกันเราจึงใช้ออบเจกต์ต่าง ๆ ในการจัดเก็บข้อมูลซึ่งหมายความว่าเรามีคลาส 'ผู้ใช้' ที่แตกต่างกัน ฉันพยายามหลีกเลี่ยงการใช้มรดกที่นี่เพราะฉันคิดว่ามันใช้ผิด
Augusto

@Augusto: การเชื่อมต่อ?
Kramii Reinstate Monica

@Karmii ฉันไม่คิดว่าอินเตอร์เฟสจะช่วยได้ที่นี่เพราะเราจะต้องทำซ้ำตรรกะในคลาสที่แตกต่างกัน หรือเราสามารถใช้อินเทอร์เฟซแล้วมอบหมายการประมวลผลให้กับคลาสผู้ช่วย แต่นั่นไม่ใช่ OO :(
Augusto

1
@Augusto ฉันไม่เข้าใจปัญหา: "procs ที่เก็บไว้ส่งคืนชุดข้อมูลที่น้อยที่สุดซึ่งบางครั้งก็ไม่เพียงพอที่จะเติมวัตถุ" ดังนั้นคุณจึงเปลี่ยน sproc หรือสร้างอีกอันหนึ่งจากนั้นให้ผู้ทำแผนที่ข้อมูลทำแผนที่
NimChimpsky
โดยการใช้ไซต์ของเรา หมายความว่าคุณได้อ่านและทำความเข้าใจนโยบายคุกกี้และนโยบายความเป็นส่วนตัวของเราแล้ว
Licensed under cc by-sa 3.0 with attribution required.