ทำไมเราต้องการวัตถุเอนทิตี้ [ปิด]

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

ฉันไม่มั่นใจว่าควรมีวัตถุเอนทิตี

โดยวัตถุเอนทิตี้ฉันหมายถึงสิ่งทั่วไปที่เรามักจะสร้างสำหรับแอปพลิเคชันของเราเช่น "บุคคล", "บัญชี", "สั่งซื้อ" ฯลฯ

ปรัชญาการออกแบบปัจจุบันของฉันคือ:

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

(หมายเหตุ: ฉันได้สร้างแอพพลิเคชั่นระดับองค์กรด้วย Java EE, java folks โปรดแทนที่ค่าที่เท่าเทียมกันสำหรับตัวอย่าง. NET ของฉัน)

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

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

ฉันใช้ OR Mappers แล้ว ฉันได้เขียนไม่กี่ ฉันใช้ Java EE stack, CSLA และอื่น ๆ ที่เทียบเท่า ฉันไม่เพียง แต่ใช้มันเท่านั้น แต่ยังพัฒนาและดูแลแอพพลิเคชั่นเหล่านี้อย่างต่อเนื่องในสภาพแวดล้อมการผลิต

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

ลองพิจารณาตัวอย่างง่ายๆนี้: คุณได้รับการสนับสนุนการโทรเกี่ยวกับหน้าบางหน้าในแอปพลิเคชันของคุณที่ทำงานไม่ถูกต้องอาจเป็นหนึ่งในฟิลด์ที่ไม่ได้ถูกยืนยันเหมือนที่ควรจะเป็น ด้วยรูปแบบของฉันนักพัฒนาที่ได้รับมอบหมายในการค้นหาปัญหาเปิดตรง 3 ไฟล์ ASPX, ASPX.CS และไฟล์ SQL ที่มีโพรซีเดอร์ที่เก็บไว้ ปัญหาซึ่งอาจเป็นพารามิเตอร์ที่ขาดหายไปจากการเรียกโพรซีเดอร์ที่เก็บไว้ใช้เวลาในการแก้ไขไม่กี่นาที แต่ด้วยเอนทิตีโมเดลใด ๆ คุณจะเริ่มทำงานดีบั๊กเริ่มก้าวผ่านโค้ดและคุณอาจเปิดไฟล์ 15-20 ไฟล์ใน Visual Studio เมื่อคุณก้าวลงมาที่ด้านล่างของสแต็คคุณลืมตำแหน่งที่คุณเริ่ม เราสามารถเก็บสิ่งต่าง ๆ ไว้ในหัวได้ในคราวเดียวเท่านั้น ซอฟต์แวร์มีความซับซ้อนอย่างเหลือเชื่อโดยไม่ต้องเพิ่มเลเยอร์ที่ไม่จำเป็นใด ๆ

ความซับซ้อนและการแก้ไขปัญหาการพัฒนาเป็นเพียงด้านเดียวของฉัน

ตอนนี้เรามาพูดเกี่ยวกับความยืดหยุ่น

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

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

ฉันไม่ใช่คนกระตือรือร้น ฉันสามารถมั่นใจได้ถ้าฉันผิดและอาจเป็นเพราะมีแรงผลักดันอย่างมากต่อ Linq ไปยัง Sql, ADO.NET EF, Hibernate, Java EE ฯลฯ โปรดคิดถึงการตอบสนองของคุณหากฉันพลาดบางสิ่งที่ฉันทำ อยากรู้ว่ามันคืออะไรและทำไมฉันจึงควรเปลี่ยนความคิดของฉัน

[แก้ไข]

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

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

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

ถามคนที่อยู่ในอุตสาหกรรมมาเป็นเวลานานและทำงานกับแอปพลิเคชันที่มีอายุใช้งานยาวนาน: แอปพลิเคชันและเลเยอร์ UI มีมากี่ครั้งแล้วและหายไปในขณะที่ฐานข้อมูลใช้งานอยู่ ยากแค่ไหนที่จะปรับและสร้างฐานข้อมูลใหม่เมื่อมีเลเยอร์การคงอยู่ที่แตกต่างกัน 4 หรือ 5 ชั้นที่สร้าง SQL เพื่อรับข้อมูล คุณไม่สามารถเปลี่ยนแปลงอะไร! ORMs หรือรหัสใด ๆ ที่สร้าง SQL จะล็อคฐานข้อมูลของคุณในทันที

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

ดังนั้นฉันจะบอกว่าไม่มีคำตอบที่เหมาะกับทุกขนาด นักพัฒนาจำเป็นต้องทราบว่าบางครั้งการพยายามเป็น OO ด้วยเกินไปอาจทำให้เกิดปัญหามากกว่าที่จะแก้

ทฤษฎีบอกว่าการติดตั้งใช้งานที่แน่นหนาและแน่นหนาเป็นหนทางไปข้างหน้า

ดังนั้นฉันคิดว่าคุณกำลังตั้งคำถามกับวิธีการนั้นนั่นคือการแยกข้อกังวลออก

ไฟล์ aspx.cs ของฉันควรโต้ตอบกับฐานข้อมูลการเรียก sproc และทำความเข้าใจกับ IDataReader หรือไม่

ในสภาพแวดล้อมแบบทีมโดยเฉพาะอย่างยิ่งที่คุณมีบุคลากรด้านเทคนิคน้อยลงที่เกี่ยวข้องกับแอพพลิเคชั่นส่วน aspx ฉันไม่ต้องการให้คนเหล่านี้สามารถ "สัมผัส" สิ่งนี้ได้

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

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

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

ความคิดที่น่าสนใจแม้ว่ามันจะรู้สึกแค่เพียงขั้นตอนเดียวจาก SQL ใน aspx ซึ่งจากวันงูเห่าที่ไม่มีโครงสร้างเก่าของฉัน แต่กลับทำให้ฉันกลัว

เหตุผลหนึ่ง - แยกโมเดลโดเมนของคุณจากโมเดลฐานข้อมูลของคุณ

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

สำหรับฉันแล้วฉันไม่ต้องการให้แอปพลิเคชันของฉันกังวลเกี่ยวกับวิธีการจัดเก็บข้อมูล ฉันอาจจะโดนตบเพราะสิ่งนี้ ... แต่แอปพลิเคชันของคุณไม่ใช่ข้อมูลของคุณข้อมูลเป็นสิ่งประดิษฐ์ของแอปพลิเคชัน ฉันต้องการให้แอปพลิเคชันของฉันคิดในแง่ของลูกค้าคำสั่งซื้อและไอเท็มไม่ใช่เทคโนโลยีอย่าง DataSets, DataTables และ DataRows ... เพราะใครจะรู้ว่าจะต้องใช้เวลานานแค่ไหน

ฉันยอมรับว่ามักจะมีการแต่งงานกันเสมอ แต่ฉันชอบที่จะแต่งงานกันมากกว่าที่จะลง ฉันสามารถปรับแต่งแขนขาและใบของต้นไม้ได้ง่ายกว่าที่ฉันสามารถเปลี่ยนลำต้นได้

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

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

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

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

ทุกบรรทัดของรหัสควรดูด้วยความสงสัย

ฉันต้องการตอบด้วยตัวอย่างที่คล้ายกับที่คุณเสนอ

ใน บริษัท ของฉันฉันต้องสร้างส่วน CRUD ง่าย ๆ สำหรับผลิตภัณฑ์ฉันสร้างเอนทิตีทั้งหมดของฉันและ DAL แยกต่างหาก หลังจากนั้นผู้พัฒนารายอื่นก็ต้องเปลี่ยนตารางที่เกี่ยวข้องและเขาก็เปลี่ยนชื่อหลายสาขา ไฟล์เดียวที่ฉันต้องเปลี่ยนเพื่ออัปเดตฟอร์มของฉันคือ DAL สำหรับตารางนั้น

สิ่งที่หน่วยงาน (ในความเห็นของฉัน) นำมาสู่โครงการคือ:

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

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

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

ในที่สุดฉันต้องการเพิ่มว่าผู้ทำแผนที่ ORM ส่วนใหญ่สนับสนุนขั้นตอนการจัดเก็บเนื่องจากเป็นสิ่งที่คุณใช้

ไชโย

ฉันคิดว่าคุณอาจ "กัดมากกว่าที่คุณสามารถเคี้ยวได้" ในหัวข้อนี้ เท็ด Neward ไม่ได้เป็นทะลึ่งเมื่อเขาเรียกมันว่า " เวียดนามวิทยาการคอมพิวเตอร์ "

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

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

หากคุณต้องการอ่านเพิ่มเติมทั้งสองด้านโปรดดูบทความในบล็อกของ Ted, Ayende Rahein, Jimmy Nilson, Scott Bellware, Alt.Net, Stephen Forte, Eric Evans เป็นต้น

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

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

เอนทิตีวัตถุสามารถอำนวยความสะดวกในการแคชบนชั้นแอพลิเคชัน ขอให้โชคดีในการแคชชุดข้อมูล

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

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

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

มีความแตกต่างระหว่างเอนทิตีและตารางของคุณ เอนทิตีควรแสดงแบบจำลองของคุณตารางเพียงแสดงด้านข้อมูลของแบบจำลองของคุณ!

เป็นความจริงที่ว่าข้อมูลมีอายุการใช้งานยาวนานกว่าแอพ แต่ให้พิจารณาข้อความอ้างอิงนี้จากDavid Laribee : รุ่นนี้เป็นนิรันดร์ ... ข้อมูลเป็นผลข้างเคียงที่มีความสุข

ลิงก์เพิ่มเติมในหัวข้อนี้:

• ทำไม Setters และ Getters ถึงชั่วร้าย

• การกลับมาของ OO บริสุทธิ์

• POJO กับ NOJO

• ซุปเปอร์โมเดลตอน 2

• TDD, Mocks และการออกแบบ

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

void exportOrder(Order order, String fileName){...};

ไม่เกี่ยวข้องกับคำสั่งที่มาจาก - จาก DB จากคำขอของเว็บจากการทดสอบหน่วย ฯลฯ ทำให้วิธีนี้ประกาศอย่างชัดเจนมากขึ้นว่าต้องการอะไรแทนที่จะใช้ DataRow และจัดทำเอกสารคอลัมน์ที่คาดว่าจะมีและควรเป็นประเภทใด เป็น เช่นเดียวกับถ้าคุณใช้มันอย่างใดเป็นขั้นตอนการจัดเก็บ - คุณยังคงต้องผลักดันการบันทึก ID ไปในขณะที่มันไม่จำเป็นต้องมีอยู่ในฐานข้อมูล

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

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

ความสามารถในการปรับขยายเป็นจุดที่น่าสนใจที่นี่ - เว็บไซต์ส่วนใหญ่ที่ต้องการความสามารถในการขยายขนาดใหญ่ (เช่น facebook, livejournal, flickr) มักจะใช้วิธี DB-ascetic เมื่อฐานข้อมูลถูกใช้น้อยที่สุดและแก้ไขปัญหาความยืดหยุ่นได้ http://highscalability.com/มีบทความที่น่าสนใจอยู่บ้าง

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

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

ฉันสามารถเข้าใจความเกลียดชังของคุณต่อ ORM ถ้าประสบการณ์ของคุณส่วนใหญ่ประกอบด้วย Java EE และ CSLA คุณอาจต้องการดู LINQ ไปยัง SQL ซึ่งเป็นเฟรมเวิร์กที่มีน้ำหนักเบามากและโดยหลักแล้วจะเป็นการแมปแบบหนึ่งต่อหนึ่งกับตารางฐานข้อมูล แต่โดยปกติจะต้องการเพียงส่วนขยายย่อยเพียงเล็กน้อย LINQ to SQL ยังสามารถแมปวัตถุอินพุตและเอาท์พุตไปยังพารามิเตอร์และผลลัพธ์ของโพรซีเดอร์ที่เก็บไว้

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

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

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

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

แต่ถ้าไม่มีวัตถุเอนทิตีพวกเขาจะไม่พูดมากนัก

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

นี้ช่วยประหยัดเวลาเมื่อมันมาถึงการบำรุงรักษา

ด้วยการแยกตรรกะของแอปพลิเคชันจากตรรกะการนำเสนอและการเข้าถึงข้อมูลและด้วยการส่ง DTO ระหว่างพวกเขาคุณจะแยกพวกมันออก อนุญาตให้พวกเขาเปลี่ยนอย่างอิสระ

คุณอาจพบโพสต์นี้ใน comp.object ที่น่าสนใจ

ฉันไม่ได้อ้างว่าเห็นด้วยหรือไม่เห็นด้วย แต่มันน่าสนใจและ (ฉันคิดว่า) เกี่ยวข้องกับหัวข้อนี้

คำถาม: คุณจะจัดการกับแอพพลิเคชั่นที่ไม่เชื่อมต่อได้อย่างไรหากตรรกะทางธุรกิจทั้งหมดของคุณติดอยู่ในฐานข้อมูล

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

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

ไม่เป็นไรสำหรับสภาพแวดล้อมบางประเภท แต่ไม่ครอบคลุมถึงแอพพลิเคชั่นระดับองค์กรทั้งหมด

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

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

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

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

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

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

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

เอริค

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

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

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

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

ฉันไม่แน่ใจจริงๆว่าคุณคิดอย่างไรกับ "แอปพลิเคชันระดับองค์กร" แต่ฉันได้รับความประทับใจที่คุณกำหนดไว้ว่าเป็นแอปพลิเคชันภายในที่ RDBMS จะถูกตั้งค่าในหินและระบบจะไม่ต้องทำงานร่วมกับระบบอื่น ๆ ไม่ว่าจะเป็นภายในหรือภายนอก

แต่ถ้าคุณมีฐานข้อมูลที่มี 100 ตารางซึ่งเท่ากับ 4 กระบวนงานที่เก็บไว้สำหรับแต่ละตารางเพียงสำหรับการดำเนินการ CRUD ขั้นพื้นฐานนั่นคือ 400 ขั้นตอนการจัดเก็บที่จำเป็นต้องได้รับการบำรุงรักษาและไม่ได้พิมพ์อย่างรุนแรง . จะเกิดอะไรขึ้นเมื่อคุณได้รับ CTO ใหม่ที่เป็นโอเพ่นซอร์สคอลลิสต์และต้องการเปลี่ยน RDBMS จาก SQL Server เป็น MySql

ซอฟต์แวร์จำนวนมากในปัจจุบันไม่ว่าจะเป็นแอปพลิเคชันระดับองค์กรหรือผลิตภัณฑ์ที่กำลังใช้ SOA และมีข้อกำหนดบางประการสำหรับการเปิดเผยบริการบนเว็บอย่างน้อยซอฟต์แวร์ที่ฉันเป็นและเกี่ยวข้องกับการทำ โดยใช้วิธีการของคุณคุณจะสิ้นสุดการเปิดเผย DataTable อนุกรมหรือ DataRows ตอนนี้อาจถือว่ายอมรับได้หากลูกค้ารับประกันว่าจะเป็น. NET และบนเครือข่ายภายใน แต่เมื่อลูกค้าไม่ทราบคุณควรพยายามออกแบบ API ซึ่งใช้งานง่ายและในกรณีส่วนใหญ่คุณไม่ต้องการเปิดเผยสกีมาฐานข้อมูลแบบเต็ม แน่นอนว่าฉันไม่ต้องการอธิบายให้ผู้พัฒนา Java ทราบว่า DataTable คืออะไรและใช้งานอย่างไร นอกจากนี้ยังมีการพิจารณาแบนด์วิดท์และขนาดของข้อมูลและ DataTables ต่อเนื่องชุดข้อมูลหนักมาก

ไม่มี bullet เงินที่มีการออกแบบซอฟต์แวร์และมันขึ้นอยู่กับว่าลำดับความสำคัญโกหกสำหรับฉันมันอยู่ในรหัส Unit Testable และส่วนประกอบที่ประกอบกันอย่างหลวม ๆ ที่สามารถบริโภคได้อย่างง่ายดายเป็นไคลเอนต์ใด ๆ

แค่ 2 เซ็นต์ของฉัน

ฉันต้องการเสนอมุมอีกมุมสำหรับปัญหาระยะทางระหว่าง OO และ RDB: ประวัติ

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

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

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

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

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

Prevayler และ db4o เป็นคำแนะนำบางอย่างฉันแน่ใจว่ามีคนอื่นที่ฉันไม่เคยได้ยินมาก่อน

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

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

ฉันจะดีใจอย่างมีความสุขเมื่อปิดช่องว่างให้ดี ฉันคิดว่าโซลูชันจะมาเมื่อ Oracle เปิดตัวบางอย่างเช่น "Oracle Object Instance Base" หากต้องการติดตามอย่างจริงจังจะต้องมีชื่อที่มั่นใจ

ไม่มากในขณะนี้ แต่เพิ่งออกจากหัวของฉัน ...

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

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

นี่คือบางสิ่งที่คุณควรจำไว้ (IMO) ว่า:

1. รหัส SQL ที่สร้างขึ้นไม่ดี (ข้อยกเว้นที่ต้องติดตาม) ขออภัยฉันรู้ว่าผู้คนจำนวนมากคิดว่ามันช่วยประหยัดเวลาได้มาก แต่ฉันไม่เคยพบระบบที่สามารถสร้างโค้ดที่มีประสิทธิภาพมากกว่าสิ่งที่ฉันสามารถเขียนได้และบ่อยครั้งที่รหัสนั้นแย่มาก ๆ คุณมักท้ายสร้างรหัส SQL ที่ไม่เคยใช้ ข้อยกเว้นที่นี่คือรูปแบบที่ง่ายมากเช่นอาจเป็นตารางการค้นหา ผู้คนจำนวนมากดำเนินไปกับมันแม้ว่า
2. เอนทิตี <> ตาราง (หรือเอนทิตีโมเดลข้อมูลตรรกะจำเป็น) ตัวแบบข้อมูลมักจะมีกฎข้อมูลที่ควรบังคับใช้อย่างใกล้ชิดกับฐานข้อมูลให้มากที่สุดซึ่งอาจรวมถึงกฎเกี่ยวกับความเกี่ยวข้องของแถวของตารางกับกฎอื่น ๆ หรือกฎที่คล้ายกันที่ซับซ้อนเกินไปสำหรับ RI ที่เปิดเผย สิ่งเหล่านี้ควรได้รับการจัดการในขั้นตอนการจัดเก็บ หากโพรซีเดอร์ที่เก็บไว้ทั้งหมดของคุณเป็นโพรเซส CRUD อย่างง่ายคุณไม่สามารถทำได้ ยิ่งไปกว่านั้นรุ่น CRUD มักจะสร้างปัญหาด้านประสิทธิภาพเนื่องจากมันไม่ได้ลดการเดินทางไปกลับระหว่างเครือข่ายกับฐานข้อมูล มักจะเป็นคอขวดที่ใหญ่ที่สุดในแอปพลิเคชันระดับองค์กร

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

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

แอปพลิเคชันที่มีโดเมนตรรกะแยกจากตรรกะการจัดเก็บข้อมูลสามารถปรับให้เข้ากับแหล่งข้อมูลใด ๆ (ฐานข้อมูลหรืออื่น ๆ ) หรือแอปพลิเคชัน UI (เว็บหรือ windows (หรือ linux เป็นต้น))

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

นอกจากนี้ตรรกะของโดเมนยังช่วยให้ UI หายไปซึ่งอาจมีความสำคัญมากกว่าในระบบที่ซับซ้อนขนาดใหญ่ที่มีการพัฒนา UIs (โดยเฉพาะเมื่อพวกเขาค้นหาลูกค้าเพิ่มขึ้นเรื่อย ๆ )

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

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

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

คำถามที่น่าสนใจ ความคิดสองสาม:

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

คำถามที่ดี!

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

ตัวอย่างเช่น,

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

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

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

วัตถุในแอพของฉันมักจะเกี่ยวข้องกับฐานข้อมูลแบบหนึ่งต่อหนึ่ง แต่ฉันค้นหาโดยใช้ Linq To Sql แทนที่จะเป็น sprocs ทำให้การเขียนข้อความค้นหาที่ซับซ้อนง่ายขึ้นโดยเฉพาะอย่างยิ่งความสามารถในการสร้างโดยใช้การประมวลผลที่เลื่อนออกไป เช่นจาก r ใน Images.User.Ratings ที่อื่น ๆ สิ่งนี้ช่วยให้ฉันพยายามหาคำสั่งการเข้าร่วมหลาย ๆ คำสั่งใน sql และการข้าม & ใช้สำหรับการเพจยังทำให้โค้ดง่ายขึ้นแทนที่จะฝังโค้ด row_number & 'over'

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