ตรรกะทางธุรกิจเป็นของเซิร์ฟเวอร์หรือไม่

สแต็กทั่วไปสำหรับเว็บแอ็พพลิเคชันคือฐานข้อมูลเซิร์ฟเวอร์ที่มีโค้ดฝั่งเซิร์ฟเวอร์และผู้ใช้ที่มีเบราว์เซอร์ที่มี HTML / CSS / JavaScript

ก่อนที่จะ AJAX ที่กว้างขวาง MVC ซึ่งคอนโทรลเลอร์เป็นโค้ดฝั่งเซิร์ฟเวอร์ rulled เซิร์ฟเวอร์ต้องกำหนดเส้นทางการร้องขอคำตอบสำหรับหน้าเว็บแบบไดนามิก (เช่นโซลูชัน html templated เช่น JSP และ ASP) เซิร์ฟเวอร์เพื่อประสานการโทรไปยังฐานข้อมูลและตัดสินใจว่าจะใช้เพจแบบไดนามิกใดเพื่อตอบคำขอหน้า ผลลัพธ์ทั้งหมดนี้คือเซิร์ฟเวอร์นั้นมีตรรกะทางธุรกิจแม้ว่าตรรกะทางธุรกิจจะไม่เชื่อมโยงกับแนวคิดในการแสดงหน้าเว็บ

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

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

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

มันจะสมเหตุสมผลหรือไม่ที่จะรวมเซิร์ฟเวอร์และฐานข้อมูลหรือสร้างโซลูชัน ERP เช่นฟังก์ชัน SAP เป็นเซิร์ฟเวอร์

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

มีแอปพลิเคชันในโลกแห่งความเป็นจริงที่เว็บเซิร์ฟเวอร์ไม่ได้ทำอะไรนอกจากเปิดเผย API ของแอปพลิเคชันเซิร์ฟเวอร์ผ่านบริการเว็บหรือ JSON

แม้กระทั่งก่อนหน้า Web 2.0 และ AJAX มันก็ไม่ถือว่าเป็นการปฏิบัติที่ดีที่สุดในการผสมผสานตรรกะทางธุรกิจของคุณกับหน้า ASP มันถือว่าดีกว่าที่จะมีตรรกะทางธุรกิจที่เป็นอิสระและมีส่วนเซิร์ฟเวอร์ของตรรกะการนำเสนออยู่ใน ASP, JSP หรืออะไรก็ตาม ดังนั้นการเปลี่ยนแปลงที่แท้จริงจาก web 2.0 ก็คือเลเยอร์การนำเสนออาจเป็น javascript ทั้งหมด ฉันชอบสิ่งนี้มากกว่า

JavaScript มักจะใช้บริการ RESTful ซึ่งหมายความว่าจะระบุแบบสอบถามฐานข้อมูล

นี่คือสิ่งที่คุณเข้าใจผิด REST ไม่ใช่ CRUD

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

ตัวอย่างง่าย ๆ : แอพที่คล้ายทวิตเตอร์ได้รับทวีตเป็นข้อความ POST บนคอนเทนเนอร์ที่กำหนด เซิร์ฟเวอร์จะวิเคราะห์บริบท ("คุณเป็นใคร?", "ช่องนี้คือช่องใด" และเนื้อหา ("แฮชแท็กใด ๆ " ดัชนีข้อความ ฯลฯ ) และจัดเก็บทั้งหมดนี้ในคิวที่เกี่ยวข้อง อาจเพิ่มการอ้างอิงโดยตรงกับผู้ติดตามทั้งหมดของคุณ

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

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

อย่างไรก็ตามคิดถึงความสามารถในการปรับขนาดการบำรุงรักษาและความปลอดภัยของผลิตภัณฑ์

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

ความคิดในการรักษาตรรกะทางธุรกิจใน javascript ที่ทำงานบนเว็บเบราว์เซอร์ซึ่งเบราว์เซอร์ที่แตกต่างกันจะต้องตอบสนองต่อ javascriopt ที่แตกต่างกันเบราว์เซอร์หลายรุ่น ฯลฯ ... ทำไมจึงทำให้ปัญหานี้ซับซ้อนกว่าเดิม?

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

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

คำตอบสั้น ๆ คือส่วนใหญ่เกี่ยวกับการบริหารความเสี่ยงและการตรวจสอบและปรับปรุงประสิทธิภาพ

ในรายละเอียด:

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

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

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

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

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

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

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