MVC: รุ่นที่มีประชากรเต็มหรือรุ่นที่เต็มไปบางส่วน?


10

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

บางครั้งดูเหมือนผิดกฎหมายที่จะเติมรายการของวัตถุจำลอง 20 แบบด้วยค่าทั้งหมดจากฐานข้อมูลเมื่อคุณรู้ว่าคุณต้องการเพียงบางส่วนเท่านั้น

แน่นอนว่าโมเดลบางส่วนหมายความว่าคุณจะต้องเขียนอีกหนึ่งวิธีใน DAO ของคุณนอกเหนือจากวิธีที่ดึงข้อมูลทุกอย่าง ซึ่งหมายถึงรหัสเพิ่มเติมในการรักษา?

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

ฉันสามารถดู ORM (เช่น Hibernate หรือ ActiveRecord of Rails) ซึ่งเป็นที่นิยมในแนวโน้มการเขียนโปรแกรม MVC และฐานข้อมูลเช่น BigTable ของ Google ซึ่งเป็นโมเดลเต็มรูปแบบที่เป็นที่ยอมรับ แต่ถ้าคุณยังใช้ JDBC รุ่นเก่าอยู่ล่ะ?

ฮาร์ดแวร์ราคาถูกการพัฒนามีราคาแพง เป็นเรื่องจริงหรือไม่ที่แอพจำเป็นต้องเพิ่มจำนวนคำขอเป็นสองสามแสนครั้งต่อชั่วโมง


1
"ในอีกทางหนึ่งการดึงทุกอย่างจากฐานข้อมูลด้วยโมเดลที่มีประชากรเต็มรูปแบบหมายถึงวิธีหนึ่งที่ให้บริการทั้งหมด คุณวัดค่าใช้จ่ายในการปฏิบัติงานจากการฝึกนี้หรือไม่?
S.Lott

>> จริงเหรอ? คุณวัดค่าใช้จ่ายจากการปฏิบัตินี้หรือไม่ << - ฉันคาดหวังไว้ ไม่ฉันยังไม่ได้ แต่มันน่าสนใจที่จะวัดและพิสูจน์ผิด
Pritam Barhate

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

1
ผมพบว่าบทความที่ยอดเยี่ยมที่ครอบคลุมคำถามที่เผยให้เห็นรูปแบบโดเมนของคุณเทียบกับการส่ง DTO ที่msdn.microsoft.com/en-us/magazine/ee236638.aspx
Mayo

คำตอบ:


3

คุณมีสองทางเลือก:

1) ปล่อยบางฟิลด์ในโมเดลที่ไม่ได้บรรจุ

2) สร้างโมเดล "lite" พิเศษสำหรับสถานการณ์เฉพาะของคุณ

ตัวเลือกใดขึ้นอยู่กับสองสิ่งอีกครั้ง:

a) จำนวนฟิลด์ของโมเดล "เต็ม" จะถูกละเว้น

b) โมเดล "lite" นี้จะถูกสร้างขึ้นบ่อยแค่ไหน

หากมีเพียงสองสามฟิลด์หรือมากกว่านั้นที่ไม่สามารถทำการเติมได้ก็โอเคที่จะใช้ 1)

ถ้า b) เป็นเพียงสถานการณ์ที่ไม่เหมือนใครบางทีอาจไม่มีประโยชน์ในการสร้างแบบจำลองพิเศษสำหรับกรณีการใช้งานเพียงครั้งเดียว

อีกวิธีหนึ่งคือการกำหนดรูปแบบ "lite" และสืบทอดโมเดล "เต็ม" จากนั้น


ขอบคุณสำหรับคำตอบ. มันทำให้รู้สึกถึงการทำแบบจำลอง Lite ขึ้นอยู่กับความต้องการ แต่บางครั้งฉันสงสัยว่ากลวิธีดังกล่าวจะสร้างคลาสโมเดลมากเกินไปหรือไม่? โดยเฉพาะอย่างยิ่งถ้าฉันสร้างแบบจำลองเฉพาะมุมมองแทนที่จะเป็นแบบจำลองเฉพาะกับตรรกะทางธุรกิจ
Pritam Barhate

3

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

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

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

ฮาร์ดแวร์ราคาถูก แต่จำนวนฮาร์ดแวร์ไม่สามารถทำให้การออกแบบไม่ดีทำงานได้ดี


2
>> หากมุมมองของคุณต้องการเพียง 2 คุณสมบัติจากรุ่นคุณมีโมเดลที่ไม่ถูกต้อง! << - ไม่จำเป็นต้องสวมเสมอ กรณีทั่วไปกำลังแสดงรายการผลการค้นหาในแอปพลิเคชันธุรกิจ ตัวอย่างเช่นใน CRM - ลูกค้า - ส่วนใหญ่จะแสดงเฉพาะชื่อและหนึ่งหรือ 2 ฟิลด์สำคัญในรายการค้นหา แต่ CRM จะมีฟิลด์อื่นที่เกี่ยวข้องกับลูกค้ารายนั้นค่อนข้างน้อย
Pritam Barhate

1
คำถามบอกว่าในกรณีนี้จำเป็นต้องใช้ 2 คุณสมบัติเท่านั้น
Steve

-2

โมเดลไม่ใช่ DAO

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

ในตัวอย่างของคุณ "ลูกค้า" ไม่ใช่รูปแบบโดเมน แต่เป็นเพียงวัตถุภายในโมเดล

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


ป.ล. ถ้าคุณมีลอจิกฐานข้อมูลที่อยู่ในรูปแบบแล้วมันจะผลักดันตรรกะทางธุรกิจโดเมนในตัวควบคุม
mefisto

1
ชั้นหนึ่งที่ทำทุกอย่างให้กับลูกค้าเป็นความคิดที่ไม่ดีเพราะมันยากที่จะรักษา
Andy
โดยการใช้ไซต์ของเรา หมายความว่าคุณได้อ่านและทำความเข้าใจนโยบายคุกกี้และนโยบายความเป็นส่วนตัวของเราแล้ว
Licensed under cc by-sa 3.0 with attribution required.