จะวางตรรกะทางธุรกิจไว้ใน Stored Procedure หรือไม่

มีการถกเถียงกันในหัวข้อนี้เสมอ - "ไม่ว่าจะวางตรรกะทางธุรกิจในกระบวนงานที่เก็บไว้หรือไม่ หากเราตัดสินใจที่จะไม่ใช้เครื่องมือ ORM และไม่ใส่ Business Logic ใน Stored Procedure เราจะวาง Business Logic ไว้ที่ไหน?

ในแอปพลิเคชันก่อนหน้าของฉันฉันมักจะต้องการวาง Business Logic ทั้งหมดในขั้นตอนการจัดเก็บเท่านั้น จากนั้นในรหัส. NET ฉันเรียกขั้นตอนการจัดเก็บเหล่านี้โดยใช้ Data Application Application Blocks SQLHelper เป็นต้น แต่นี่ไม่สามารถเป็นสถานการณ์ได้ตลอดเวลา ดังนั้นฉันจึงทำ googling แต่ก็สับสนในที่สุด .......

ข้อเสนอแนะใด ๆ ... ?

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

อย่างไรก็ตามจากที่เปิดใช้งาน. NET ORMS ที่เปิดใช้งาน LINQ เช่น LINQ2SQL, EF และ NHibernate ในขณะนี้จะสร้างการสืบค้น SQL ที่กำหนดพารามิเตอร์ซึ่งแผนการเคียวรีสามารถแคชไว้ได้จะถูกหลบหนีสำหรับ SQL Injection เป็นต้นฉันเดาว่าการย้ายไปสู่สถาปัตยกรรมชั้น 3 / N น่าดึงดูดยิ่งกว่าที่เคยและ SPROC ส่วนใหญ่ (โดยเฉพาะข้อความค้นหาเป็นศูนย์กลาง) สามารถหลีกเลี่ยงได้ทั้งหมด รูปแบบพื้นที่เก็บข้อมูลใน. NET มักจะเปิดเผยพารามิเตอร์ IQueryable / ยอมรับ Expression tree ช่วยให้สามารถเข้าถึงตารางของคุณได้อย่างปลอดภัย แต่มีความยืดหยุ่น (โดยส่วนตัวในสถาปัตยกรรมประเภท SOA ฉันจะไม่เปิดเผย IQueryable เกิน BLL นั่นคือระดับการบริการและการนำเสนอของคุณควรทำงานกับชุดของวิธีการที่กำหนดไว้อย่างดีเหตุผลคือมิฉะนั้นคุณจะไม่สามารถทดสอบระบบของคุณได้อย่างสมบูรณ์

อย่างไรก็ตามในระบบที่มีขนาดพอเหมาะจะมีข้อยกเว้นเล็กน้อยอยู่เสมอซึ่งชิ้นส่วนที่มีความเข้มข้นของข้อมูลจริงๆอาจยังต้องถูกเขียนเป็น Stored Proc ด้วยเหตุผลด้านประสิทธิภาพ ในกรณีเหล่านี้ฉันจะเก็บ SPROC และเปิดเผย SPROC ผ่าน ORM แต่ยังคงแสดงฟังก์ชันเป็นวิธีการส่งผ่านบน BLL ของคุณ

การเป็นนักพัฒนาจาวาการตั้งค่าของฉันคือการวางตรรกะทางธุรกิจใน BLL (การควบคุมแหล่งที่ดีและง่ายความคุ้นเคย ฯลฯ ฯลฯ )

อย่างไรก็ตามหลังจากทำงานให้กับองค์กรขนาดใหญ่ที่มีแอพพลิเคชั่นแบบกระจายจำนวนมากที่ใช้เทคโนโลยีที่แตกต่างกัน (C #, Java, Pick (ไม่ต้องถาม)) ประโยชน์ที่สำคัญอย่างหนึ่งของการใช้โพรซีเดอร์ที่เก็บไว้

วิธีการจัดเก็บสามารถใช้ร่วมกันในการใช้งานที่แตกต่างกัน

ทีมของเรามีกฎนุ่มนวลที่นี่ บางครั้งการแก้ไข Business Logic ใน T-SQL จะดีกว่าในบางครั้งมันจะง่ายกว่าใน c # (ชั้นธุรกิจ)

ดังนั้นเราจึงมีวิธีแก้ปัญหาในทางปฏิบัติ: วางในที่ที่มันเหมาะกว่า ฉันรู้ว่าบางครั้งทฤษฎีก็เข้มงวดมากเกี่ยวกับเรื่องนี้ แต่นั่นคือทฤษฎี :-)

มีข้อดีและข้อเสียทั้ง (ในความคิดของฉัน):

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

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

เราใส่ตรรกะทางธุรกิจของเราไว้ในชั้นตรรกะทางธุรกิจเสมอ หากคุณวางไว้ใน Stored Procedure มันจะหายไปเมื่อคุณเปลี่ยน RDBMS ของคุณ

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

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

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

ตรรกะควรอยู่ใน BLL เสมอเพราะ:

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

ฉันเชื่อว่าควรมีกฎหมายที่ระบุว่าหลังจาก SP มีความยาวมากกว่า X เส้นมันไม่ทำงานตามที่ตั้งใจ

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

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

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

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