วิธีที่ดีที่สุดในการค้นหาข้อมูลจาก MS SQL Server ใน C #?

วิธีที่ดีที่สุดในการสืบค้นข้อมูลจาก MS SQL Server ใน C # คืออะไร

ฉันรู้ว่ามันไม่ใช่วิธีปฏิบัติที่ดีที่จะมีคิวรี่ SQL ในโค้ด

เป็นวิธีที่ดีที่สุดในการสร้างขั้นตอนการจัดเก็บและเรียกมันจาก C # ด้วยพารามิเตอร์หรือไม่

using (var conn = new SqlConnection(connStr))
using (var command = new SqlCommand("StoredProc", conn) { CommandType = CommandType.StoredProcedure }) {
   conn.Open();
   command.ExecuteNonQuery();
   conn.Close();
}

การใช้โพรซีเดอร์ที่จัดเก็บเป็นวิธีหนึ่งและใช้กันอย่างแพร่หลายมานานหลายปี

วิธีที่ทันสมัยกว่าในการโต้ตอบกับฐานข้อมูล SQL Server จาก C # (หรือภาษา. NET ใด ๆ ) คือการใช้ Entity Framework ข้อดีของ Entity Framework ก็คือมันให้ระดับที่สูงกว่าของนามธรรม

อ้างจาก Microsoft ( https://msdn.microsoft.com/en-us/data/jj590134 ):

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

• แอปพลิเคชันสามารถทำงานในรูปแบบของแนวคิดรวบยอดแอปพลิเคชันเป็นศูนย์กลางมากขึ้นรวมถึงประเภทที่มีการสืบทอดสมาชิกที่ซับซ้อนและความสัมพันธ์
• แอปพลิเคชันนั้นเป็นอิสระจากการพึ่งพาฮาร์ดโค้ดในเอ็นจินข้อมูลหรือสกีมาหน่วยเก็บข้อมูลเฉพาะ
• การแม็พระหว่างโมเดลแนวคิดและสกีมาเฉพาะหน่วยเก็บข้อมูลสามารถเปลี่ยนแปลงได้โดยไม่ต้องเปลี่ยนโค้ดแอ็พพลิเคชัน
• นักพัฒนาสามารถทำงานกับโมเดลวัตถุของแอปพลิเคชันที่สอดคล้องกันซึ่งสามารถแมปเข้ากับสคีมาหน่วยเก็บข้อมูลต่างๆซึ่งอาจนำไปใช้ในระบบการจัดการฐานข้อมูลที่แตกต่างกัน
• โมเดลโมเดลเชิงแนวคิดหลายโมเดลสามารถแม็พกับสกีมาหน่วยเก็บข้อมูลเดียว
• ส่วนสนับสนุน Language-integrated query (LINQ) ให้การตรวจสอบความถูกต้องทางไวยากรณ์เวลาคอมไพล์สำหรับแบบสอบถามกับโมเดลแนวคิด

การใช้ ORM กับขั้นตอนการจัดเก็บเกี่ยวข้องกับการแลกเปลี่ยนโดยเฉพาะอย่างยิ่งในแง่ของการรักษาความปลอดภัยและที่ตั้งของตรรกะ

แนวทาง "คลาสสิค" เพื่อการพัฒนากับ SQL Server คือการให้ตรรกะของแอปพลิเคชันอยู่ในขั้นตอนการจัดเก็บและโปรแกรมที่ให้สิทธิ์ด้านความปลอดภัยในการดำเนินการขั้นตอนการจัดเก็บเท่านั้นไม่ใช่การอัพเดทตารางโดยตรง แนวคิดในที่นี้คือกระบวนงานที่เก็บไว้เป็นเลเยอร์ตรรกะทางธุรกิจสำหรับแอปพลิเคชัน ในขณะที่ทฤษฎีเสียงมันมีแนวโน้มที่จะหลุดพ้นจากความโปรดปรานด้วยเหตุผลต่าง ๆ ถูกแทนที่ด้วยการใช้ตรรกะทางธุรกิจในการเขียนโปรแกรมภาษาเช่น C # หรือ VB แอปพลิเคชันที่ดียังคงใช้งานด้วยวิธีการที่ทำเป็นชั้นรวมถึงการแยกข้อกังวล ฯลฯ แต่มีแนวโน้มที่จะทำตามรูปแบบเช่น MVC

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

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

จริงๆแล้วการยืนยันขั้นพื้นฐานนั้นเป็นที่ถกเถียงกัน - มีการแลกเปลี่ยนกันระหว่างวิธีที่มี SQL ในรหัสหรือมีรหัสในฐานข้อมูล

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

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

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

ฉันจะเป็นอิสระฉันมักจะทำงานในโครงการขนาดเล็กที่มีทีมเล็ก (1-3 devs) - การใช้โพรซีเดอร์ที่เก็บไว้สำหรับฉันมีปัญหามากกว่าความคุ้มค่าเพราะธรรมชาติของแอปพลิเคชันของเรา โดยทั่วไปรหัสนั้นง่ายกว่าการอัพเดต schema (แม้จะอนุญาตให้ฉันมีรหัสที่ทำให้การปรับปรุง schema ค่อนข้างตรงไปตรงมา) และฉันสามารถบังคับใช้กฎเกณฑ์ทางธุรกิจโดยใช้รหัสการเข้าถึงข้อมูลทั่วไป นี่เป็นตัวอย่างที่ชัดเจนของ "Your Mileage May Vary"

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

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

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

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

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