เหตุใดนักพัฒนาจึงควรใช้บริการเว็บแทนการเชื่อมต่อโดยตรงกับฐานข้อมูล [ปิด]

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

นี่คือสิ่งที่ฉันคิดขึ้นมา อีกไหม?

1. บริการเว็บ WCF หากกำหนดค่าอย่างถูกต้องจะปลอดภัยมากขึ้น
2. การเปลี่ยนแปลง DB จำเป็นต้องทำที่ระดับเซอร์วิสเท่านั้น (ไฟล์ config หรือรีคอมไพล์เซอร์วิส)
3. เมื่อตั้งค่าและโฮสต์แล้วบริการบนเว็บจะใช้งานได้ง่ายขึ้น

1. ความปลอดภัย. คุณไม่ได้ให้สิทธิ์การเข้าถึง DB แก่ทุกคนยกเว้นผู้ใช้เว็บเซิร์ฟเวอร์ / แอป

   สิ่งนี้สำคัญเป็นพิเศษเมื่อคุณมีผู้ใช้จำนวนมาก คุณหลีกเลี่ยงความเจ็บปวดจากการดูแลผู้ใช้ / บทบาทในฝั่ง DB

2. การลดโหลด DB บริการบนเว็บสามารถแคชข้อมูลที่ดึงมาจาก DB

3. การเชื่อมต่อฐานข้อมูลร่วมกัน (hat / tip @Dogs)

   เว็บเซอร์วิสสามารถใช้พูลขนาดเล็กของการเชื่อมต่อ DB ที่เปิดถาวร ความช่วยเหลือในหลาย ๆ วิธี:

   • พูลการเชื่อมต่อ DB ถูก จำกัด ที่ฝั่งเซิร์ฟเวอร์ฐานข้อมูล

   • การเปิดการเชื่อมต่อ DB ใหม่มีค่าใช้จ่ายสูงมาก (โดยเฉพาะกับเซิร์ฟเวอร์ฐานข้อมูล)

4. ความสามารถในการยอมรับข้อผิดพลาด - บริการสามารถสลับระหว่างแหล่งข้อมูลหลัก / DR ได้โดยไม่ต้องมีรายละเอียดของความล้มเหลวในการใช้งานโดยผู้ใช้บริการ

5. ความสามารถในการปรับขนาด - บริการสามารถกระจายคำขอระหว่างแหล่งข้อมูลแบบขนานหลายแหล่งโดยไม่ต้องมีรายละเอียดของการหยิบทรัพยากรโดยผู้ใช้บริการ

6. การห่อหุ้ม คุณสามารถเปลี่ยนการนำฐานข้อมูลไปใช้งานได้โดยไม่กระทบกับผู้ใช้บริการ

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

8. อาจมีผลกับคุณหรือไม่ก็ได้ - การตัดสินใจเกี่ยวกับสถาปัตยกรรมบางอย่างไม่เป็นมิตรกับ DB acces เช่นเซิร์ฟเวอร์ Java ที่ทำงานบน Unix สามารถเข้าถึงฐานข้อมูลได้ง่ายในขณะที่ไคลเอนต์ java ที่ทำงานบนพีซี Windows จะไม่ทราบฐานข้อมูลและคุณอาจต้องการให้เป็น

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

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

นอกจากนี้คุณยังสามารถดูรายการดีๆได้ในหน้านี้: 'Encapsulating Database Access: An Agile "Best" Practice'

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

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

1. ไม่มีเหตุผลว่าทำไมการเชื่อมต่อฐานข้อมูลจึงไม่ปลอดภัย
2. คุณสามารถห่อหุ้มฐานข้อมูลในชั้นการเข้าถึงข้อมูล (อาจเป็น Entity Framework)
3. บริการบนเว็บไม่ง่ายต่อการใช้งานไปกว่าเลเยอร์การเข้าถึงข้อมูลที่เขียนไว้อย่างดี

• Web Services สร้าง API โดยกำหนดการโต้ตอบที่อนุญาตระหว่างระบบภายนอกและข้อมูลของแอปพลิเคชัน
• บริการเว็บแยกฐานข้อมูลออกจากการโต้ตอบภายนอกและทำให้ชั้นข้อมูลสามารถจัดการได้โดยไม่ขึ้นอยู่กับอิทธิพลภายนอกเหล่านั้น
• การอนุญาตให้เข้าถึงโดย Web Services เท่านั้นช่วยให้มั่นใจได้ว่าตรรกะของแอปพลิเคชันได้รับโอกาสในการดำเนินการปกป้องความสมบูรณ์ของข้อมูล
• บริการบนเว็บอนุญาตให้ใช้มาตรการการพิสูจน์ตัวตน / การอนุญาตที่เหมาะสมที่สุดซึ่งตรงข้ามกับฐานข้อมูลที่ต้องใช้ชื่อผู้ใช้และรหัสผ่าน / สิทธิ์ระดับตาราง
• บริการเว็บให้โอกาสสำหรับการค้นหาบริการอัตโนมัติและการกำหนดค่าที่จะใช้
• การรับส่งข้อมูลบริการเว็บสามารถเข้ารหัสสำหรับการส่งผ่านเครือข่ายที่ไม่ปลอดภัย ไม่ทราบโซลูชันการเชื่อมต่อ DB โดยตรงที่ช่วยให้ ... ?

จุดเหล่านี้ส่วนใหญ่ใช้สำหรับ API ที่เป็นทางการไม่ใช่เฉพาะบริการเว็บ

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

ยิ่งไปกว่านั้นการเพิ่มเลเยอร์โปรโตคอลข้อความ SOAP ที่เพิ่มประสิทธิภาพให้กับเว็บแอปที่ถูก 'บังคับ' ให้ออกเดทกับ 'หมู' นี้ ตอนนี้ฉันกำลังทำโปรเจ็กต์ที่แอพ MVC-4 ใหม่ของเราได้รับคำสั่งให้ใช้ DAL ดังกล่าว เรามีภาระที่จะต้องเปลี่ยนทั้งลายเซ็น WebMethod และลายเซ็น SP เมื่อใดก็ตามที่เรื่องราวของผู้ใช้ใหม่เกิดขึ้นพร้อมกับความจำเป็นในการเปลี่ยนแปลงดังกล่าว ซึ่งสำหรับเราคือทุกๆการวิ่ง โดยธรรมชาติแล้วในแนวทาง passthru นั้นมีสองชั้นที่เชื่อมต่อกันอย่างแน่นหนา

1) อาการปวดหัวในการบำรุงรักษาฐานข้อมูลลดลงจากฝั่งนักพัฒนาเพื่อให้พวกเขามุ่งเน้นไปที่การพัฒนาเท่านั้น

2) บริการเว็บรองรับการสื่อสารของแพลตฟอร์มต่างๆ (ระบบปฏิบัติการเช่น windows, ios, android ฯลฯ ) ด้วยวิธีการที่ง่ายและมีประสิทธิภาพ ตัวอย่างเช่นพิจารณาสถานการณ์เมื่อแอปพลิเคชัน Android และแอปพลิเคชัน ios ต้องการสื่อสารไปยังเว็บไซต์ที่ใช้ java ดังนั้นสำหรับการสื่อสารทั้งสามสิ่งนี้ webservice เป็นทางออกที่ดีที่สุดแทนที่จะดูแลฐานข้อมูลที่แตกต่างกันสามฐานข้อมูล

โดยทั่วไป

1. ระดับบริการบนเว็บส่งเสริมการนำคำขอข้อมูลทั่วไปมาใช้ซ้ำสำหรับหลายแอปพลิเคชัน
2. สามารถตั้งค่าบริการเว็บด้วยการจัดการเวอร์ชันซึ่งเบี่ยงเบนประเด็นต่างๆที่เกิดจากการพัฒนาระดับแอปพลิเคชัน ตัวอย่างเช่นถ้าฉันยังใหม่กับโปรเจ็กต์ที่ฉันใช้แอปพลิเคชันที่มีอยู่เป็นโมเดลที่ดีในการกำหนดค่าแอปพลิเคชันของฉันให้ใช้แหล่งฐานข้อมูลที่มีอยู่
3. Web Service ได้รับการพัฒนาเพื่อให้มีตัวเลือกที่ยืดหยุ่นสำหรับการส่งคำขอและรับผลลัพธ์การตอบกลับในรูปแบบทั่วไปเช่น JSON โดยใช้ URI แบบธรรมดาซึ่งหมายความว่าแอปพลิเคชันไคลเอ็นต์สามารถพัฒนาได้โดยใช้มาตรฐานทั่วไปที่สนับสนุนอินเทอร์เฟซสม่ำเสมอที่เชื่อถือได้

ฉันแค่จ้องกับ ASP.NET Web Api และวางแผนที่จะให้บริการข้อมูลก่อน

ฉันเพิ่งให้ความสำคัญกับแอปพลิเคชันเว็บ. NET MVC ด้วยการใช้กรอบงานเอนทิตี

1. หากคุณใช้ MVC อยู่แล้ว Web Api ยังใช้ MVC กับตัวควบคุม Api ดังนั้นเส้นโค้งการเรียนรู้ในการสร้างบริการจึงค่อนข้างไม่เจ็บปวด

เมื่อเร็ว ๆ นี้ฉันพบว่าตัวเองตกอยู่ในสถานการณ์ที่น่าผิดหวังกับเว็บแอป MVC ที่ฉันสร้างขึ้นโดยใช้ขั้นตอนการจัดเก็บของ Oracle เวอร์ชันดั้งเดิมในชื่อ Oracle 9 หรือก่อนหน้านี้ซึ่งทำให้เกิดปัญหาอื่นกับ Visual Studio 2012 ซึ่งผลักดันแนวทางโรงงานการเชื่อมต่อที่ทันสมัยมากขึ้นด้วยชุดประกอบเวลาในการโหลดการค้นหาไฟล์ dll ที่เหมาะสมเพื่อใช้ตามการเชื่อมต่อกำหนดค่าเว็บและชื่อ TNS

ความพยายามในการเชื่อมต่อกับฐานข้อมูลล้มเหลวโดยมีข้อความแสดงข้อผิดพลาด "ไม่รองรับอีกต่อไป" ด้วยความอยากรู้อยากเห็นฉันดาวน์โหลด Oracle 12c และทำการเชื่อมต่อระดับแอปพลิเคชันบางอย่างที่ทำงานได้ดีกับชื่อ TNS ของฉันและ dll แอสเซมบลีการโหลดและฉันก็สามารถทำงานกับ Oracle ได้โดยไม่มีปัญหา

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

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

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

ดังนั้น....

1. สำหรับปัญหาเซิร์ฟเวอร์ฐานข้อมูลหลายรายการเช่นการใช้โพรซีเดอร์ที่จัดเก็บโดย Oracle ในแอปพลิเคชัน. NET MVC ซึ่งโดยปกติแล้วอาจใช้ EF สำหรับการใช้ข้อมูล SQL Server ทำไมไม่ลองใช้วิธีการบริการ Web Api ซึ่งสามารถแยกปัญหาการกำหนดค่าเหล่านั้นได้
2. อีกครั้งการเชื่อมต่อไคลเอ็นต์สามารถทำได้โดยใช้ JavaScript, JQuery และ JSON ซึ่งคุณใช้อยู่แล้วหากคุณกำลังทำสิ่งนี้โดยใช้ Web Api เพื่อสร้างคำขอข้อมูล SQL Server

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