คำถามติดแท็ก event-programming

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

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

5
ฉันควรใช้การเขียนโปรแกรมตามเหตุการณ์เมื่อใด
ฉันได้ผ่านการเรียกกลับหรือเพียงแค่เรียกใช้ฟังก์ชันจากฟังก์ชันอื่นในโปรแกรมของฉันเพื่อทำให้สิ่งต่าง ๆ เกิดขึ้นเมื่องานเสร็จสมบูรณ์ เมื่อบางสิ่งบางอย่างเสร็จสิ้นฉันจะเรียกใช้ฟังก์ชันโดยตรง: var ground = 'clean'; function shovelSnow(){ console.log("Cleaning Snow"); ground = 'clean'; } function makeItSnow(){ console.log("It's snowing"); ground = 'snowy'; shovelSnow(); } แต่ฉันได้อ่านเกี่ยวกับกลยุทธ์ต่าง ๆ ในการเขียนโปรแกรมและกลยุทธ์ที่ฉันเข้าใจว่ามีประสิทธิภาพ แต่ยังไม่ได้ฝึกฝนนั้นเป็นเหตุการณ์ที่ใช้ (ฉันคิดว่าวิธีการที่ฉันอ่านเกี่ยวกับเรียกว่า"pub-sub" ): var ground = 'clean'; function shovelSnow(){ console.log("Cleaning Snow"); ground = 'clean'; } function makeItSnow(){ console.log("It's snowing"); ground = 'snowy'; …

2
การสื่อสารระหว่างคำสั่งซ้อน
ดูเหมือนจะมีวิธีการสื่อสารค่อนข้างน้อยระหว่างคำสั่ง สมมติว่าคุณมีคำสั่งซ้อนกันซึ่งคำสั่งภายในต้องสื่อสารบางสิ่งกับภายนอก (เช่นถูกเลือกโดยผู้ใช้) <outer> <inner></inner> <inner></inner> </outer> จนถึงตอนนี้ฉันมี 5 วิธีในการทำเช่นนี้ require: คำสั่งผู้ปกครอง innerสั่งสามารถต้องouterสั่งซึ่งสามารถเปิดเผยวิธีการบางอย่างเกี่ยวกับการควบคุมของตน ดังนั้นในinnerความหมาย require: '^outer', link: function(scope, iElement, iAttrs, outerController) { // This can be passed to ng-click in the template $scope.chosen = function() { outerController.chosen(something); } } และในouterตัวควบคุมของคำสั่ง: controller: function($scope) { this.chosen = function(something) { } } $emit …

8
กิจกรรมใช้สำหรับการเขียนโปรแกรม GUI เท่านั้นหรือไม่
กิจกรรมใช้สำหรับการเขียนโปรแกรม GUI เท่านั้นหรือไม่ คุณจัดการกับการเขียนโปรแกรมแบ็กเอนด์ปกติอย่างไรเมื่อมีบางอย่างเกิดขึ้นกับสิ่งอื่นนี้

6
การวนรอบเหตุการณ์เป็นเพียงการวนรอบ / ขณะที่การหยั่งสัญญาณที่ปรับปรุงแล้ว
ฉันพยายามเข้าใจว่าวงเหตุการณ์คืออะไร บ่อยครั้งที่คำอธิบายคือในเหตุการณ์วนรอบคุณทำบางสิ่งบางอย่างจนกว่าคุณจะได้รับแจ้งว่ามีเหตุการณ์เกิดขึ้น จากนั้นคุณจัดการกับกิจกรรมและทำสิ่งที่คุณเคยทำมาก่อน เพื่อแมปคำจำกัดความข้างต้นด้วยตัวอย่าง ฉันมีเซิร์ฟเวอร์ที่ 'คอยฟัง' ในเหตุการณ์ลูปและเมื่อตรวจพบการเชื่อมต่อซ็อกเก็ตข้อมูลจากมันจะถูกอ่านและแสดงหลังจากนั้นเซิร์ฟเวอร์จะกลับมาทำงาน / เริ่มฟังเหมือนเดิม อย่างไรก็ตามเหตุการณ์นี้เกิดขึ้นและพวกเราได้รับแจ้งว่า 'แบบนั้น' นั้นเป็นเรื่องที่ฉันต้องรับมือ คุณสามารถพูดได้ว่า: "ไม่ใช่" แบบนั้น "คุณต้องลงทะเบียนผู้ฟังเหตุการณ์" แต่สิ่งที่ฟังเหตุการณ์ แต่ฟังก์ชั่นที่ด้วยเหตุผลบางอย่างจะไม่กลับมา มันอยู่ในวงของตัวเองกำลังรอการแจ้งเตือนเมื่อมีเหตุการณ์เกิดขึ้น? ผู้ฟังเหตุการณ์ควรลงทะเบียนผู้ฟังเหตุการณ์ด้วยหรือไม่ มันจะจบที่ไหน? เหตุการณ์เป็นสิ่งที่เป็นนามธรรมที่ดีในการทำงานด้วย แต่เป็นเพียงสิ่งที่เป็นนามธรรม ฉันเชื่อว่าในท้ายที่สุดการเลือกตั้งไม่สามารถหลีกเลี่ยงได้ บางทีเราไม่ได้ทำมันในรหัสของเรา แต่ระดับที่ต่ำกว่า (การใช้ภาษาการเขียนโปรแกรมหรือระบบปฏิบัติการ) กำลังทำเพื่อเรา โดยทั่วไปแล้วจะมากับรหัสเทียมต่อไปนี้ซึ่งทำงานอยู่ในระดับต่ำพอจึงไม่ทำให้เกิดการรอคอย: while(True): do stuff check if event has happened (poll) do other stuff นี่คือความเข้าใจของฉันของความคิดทั้งหมดและฉันต้องการที่จะได้ยินว่ามันถูกต้อง ฉันเปิดกว้างในการยอมรับว่าความคิดทั้งหมดนั้นผิดอย่างสิ้นเชิงซึ่งในกรณีนี้ฉันต้องการคำอธิบายที่ถูกต้อง

6
วิธีจัดการสถานะเริ่มต้นในสถาปัตยกรรมที่ขับเคลื่อนด้วยเหตุการณ์ได้อย่างไร
ในสถาปัตยกรรมที่ขับเคลื่อนด้วยเหตุการณ์แต่ละองค์ประกอบจะทำหน้าที่เฉพาะเมื่อเหตุการณ์ถูกส่งผ่านระบบ ลองนึกภาพรถยนต์สมมุติกับแป้นเบรกและไฟเบรก ไฟเบรคจะเปิดขึ้นเมื่อได้รับเหตุการณ์brake_onและปิดเมื่อได้รับเหตุการณ์brake_off แป้นเบรกส่งเหตุการณ์brake_onเมื่อมันถูกกดลงและเหตุการณ์brake_offเมื่อมันถูกปล่อยออกมา ทั้งหมดนี้เป็นสิ่งที่ดีและดีจนกระทั่งคุณมีสถานการณ์ที่รถเปิดอยู่โดยเหยียบแป้นเบรกลงไปแล้ว เนื่องจากไฟเบรกไม่เคยได้รับเหตุการณ์brake_onมันจะหยุดอยู่ - เป็นสถานการณ์ที่ไม่พึงประสงค์อย่างชัดเจน การเปิดไฟเบรคตามค่าเริ่มต้นจะเป็นการพลิกกลับสถานการณ์เท่านั้น สิ่งที่สามารถทำได้เพื่อแก้ไข 'ปัญหาสถานะเริ่มต้น' นี้ แก้ไข:ขอบคุณสำหรับคำตอบทั้งหมด คำถามของฉันไม่เกี่ยวกับรถยนต์จริง ในรถยนต์ที่พวกเขาแก้ไขปัญหานี้โดยการส่งรัฐอย่างต่อเนื่อง - ดังนั้นจึงไม่มีปัญหาการเริ่มต้นในโดเมนนั้น ในโดเมนซอฟต์แวร์ของฉันโซลูชันนั้นจะใช้รอบ CPU ที่ไม่จำเป็นจำนวนมาก แก้ไข 2:นอกเหนือจากคำตอบของ @ gbjbaanbฉันจะใช้ระบบที่: แป้นเหยียบเบรกหลังจากการเตรียมใช้งานส่งเหตุการณ์ด้วยสถานะของมันและ ไฟเบรกตามสมมุติฐานหลังจากการเตรียมข้อมูลเบื้องต้นจะส่งเหตุการณ์ที่ขอให้เกิดเหตุการณ์สถานะจากแป้นเหยียบเบรก ด้วยโซลูชันนี้ไม่มีการพึ่งพาระหว่างคอมโพเนนต์ไม่มีสภาวะการแข่งขันไม่มีคิวข้อความให้ค้างและไม่มีคอมโพเนนต์ 'ต้นแบบ'

6
ข้อดีของระบบ“ การส่งข้อความ” กับระบบ“ ตามเหตุการณ์”
คำถามของฉันมาจากมุมมองที่ค่อนข้างไม่มีการศึกษา ข้อดีของระบบ "การส่งข้อความ " คืออะไรเทียบกับระบบ " ตามเหตุการณ์ " ทำไมหนึ่งจะเลือกหนึ่งมากกว่าอีก? จุดแข็งและจุดอ่อนของพวกเขาคืออะไร ฉันต้องการที่จะรู้ไม่เพียง แต่ "ในทางทฤษฎี" แต่ยัง "ในทางปฏิบัติ" แก้ไข: ปัญหาเฉพาะ : ฉันต้องการสร้างระบบขององค์ประกอบปลั๊กอินที่ทำงานเป็นบริการขนาดเล็ก (แต่ละงานมีภารกิจเล็ก ๆ และให้ข้อมูลบางส่วน) บริการสามารถ: เป็นเลเยอร์เพื่อให้เอาต์พุตของบริการหนึ่งสามารถทำหน้าที่เป็นหนึ่งในอินพุตไปยังอีกบริการหนึ่ง มีลำดับชั้นการกักกันเพื่อให้บริการหนึ่งสามารถถูกควบคุมได้โดยไม่ต้องมีความสัมพันธ์อินพุต - เอาท์พุตเฉพาะดังที่กล่าวไว้ในประโยคก่อนหน้า เป้าหมายของระบบคือการแปลการไหลของเหตุการณ์ระดับต่ำในระบบอื่นให้เป็นข้อมูลและการทำงานในระดับที่สูงขึ้นและนอกจากนี้ยังมีช่องทางกลับไปยังระบบอื่นที่ให้บริการกิจกรรมเดียว ฉันสามารถให้รายละเอียดเพิ่มเติมหากยังไม่เพียงพอ หลังจากดูรอบ ๆ แล้ว สิ่งนี้และนี่อาจอธิบายสถานการณ์ของฉันได้ดีขึ้น ดูเหมือนว่ามันจะเหมาะกับสถานการณ์ของฉัน: http://akka.io/

4
ปลั๊กอินควรใช้อะไร: hooks เหตุการณ์หรืออย่างอื่น?
พิจารณาแอพที่อนุญาตให้ปลั๊กอินตอบสนองต่อโฟลว์ของโปรแกรม ฉันรู้ 2 วิธีในการบรรลุเป้าหมายนี้: hooksและevents 1. ตะขอ ใช้การเรียกฟังก์ชั่นที่ว่างเปล่าภายในผังโปรแกรมหลัก ฟังก์ชั่นเหล่านี้สามารถแทนที่ได้ด้วยปลั๊กอิน ตัวอย่างเช่น Drupal CMS ใช้ฮุคที่พร้อมใช้งานกับโมดูลและธีม นี่คือตัวอย่างของวิธีการใช้เบ็ดในฟังก์ชั่นfile_copy function file_copy(stdClass $source, $destination = NULL, $replace = FILE_EXISTS_RENAME) { // ... [File copying routine] // Inform modules that the file has been copied. module_invoke_all('file_copy', $file, $source); return $file; // ... } โมดูลสามารถใช้modulename_file_copy($file, $source)ฟังก์ชั่นซึ่งจะถูกเรียกโดยในmodule_invoke_all file_copyหลังจากฟังก์ชั่นนี้เสร็จสิ้นการfile_copyดำเนินการจะดำเนินการต่อ 2. …

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

7
วิธีการลดความยุ่งยากในการบำรุงรักษาของรหัสเหตุการณ์ขับเคลื่อน?
เมื่อใช้องค์ประกอบตามเหตุการณ์ฉันมักจะรู้สึกเจ็บปวดในช่วงการบำรุงรักษา เนื่องจากโค้ดที่ถูกประมวลผลจะถูกแยกออกไปรอบ ๆ มันอาจเป็นเรื่องยากที่จะคิดว่าส่วนใดของโค้ดที่จะเกี่ยวข้องกับรันไทม์ สิ่งนี้สามารถนำไปสู่ปัญหาการดีบักที่ละเอียดและยากเมื่อมีคนเพิ่มตัวจัดการเหตุการณ์ใหม่บางอย่าง แก้ไขจากความคิดเห็น: แม้ว่าจะมีแนวปฏิบัติที่ดีเช่นการมีแอพพลิเคชั่น Event Bus และตัวจัดการที่มอบหมายธุรกิจไปยังส่วนอื่น ๆ ของแอพมีช่วงเวลาที่รหัสเริ่มอ่านยากเพราะมีจำนวนมาก ตัวจัดการการลงทะเบียนจากสถานที่ต่าง ๆ (โดยเฉพาะอย่างยิ่งจริงเมื่อมีรถบัส) จากนั้นไดอะแกรมลำดับเริ่มมองดูซับซ้อนเวลาที่ใช้ในการคิดว่าเกิดอะไรขึ้นเพิ่มขึ้นและเซสชันการดีบักยุ่งเหยิง (เบรกพอยต์บนตัวจัดการตัวจัดการในขณะที่วนรอบตัวจัดการโดยเฉพาะอย่างยิ่งสนุกสนานกับตัวจัดการ async และตัวกรองบางส่วนด้านบน) ////////////// ตัวอย่าง ฉันมีบริการที่ดึงข้อมูลบางอย่างบนเซิร์ฟเวอร์ ในไคลเอนต์เรามีองค์ประกอบพื้นฐานที่เรียกใช้บริการนี้โดยใช้การโทรกลับ เพื่อให้จุดส่วนขยายแก่ผู้ใช้ของส่วนประกอบและเพื่อหลีกเลี่ยงการเชื่อมต่อระหว่างส่วนประกอบที่แตกต่างกันเรากำลังยิงเหตุการณ์บางอย่าง: หนึ่งก่อนที่จะส่งแบบสอบถามแบบสอบถามหนึ่งเมื่อคำตอบกลับมาและอีกคนหนึ่งในกรณีของความล้มเหลว เรามีชุดพื้นฐานของตัวจัดการที่ลงทะเบียนล่วงหน้าซึ่งให้พฤติกรรมเริ่มต้นขององค์ประกอบ ตอนนี้ผู้ใช้ของส่วนประกอบ (และเราเป็นผู้ใช้ของคอมโพเนนต์ด้วย) สามารถเพิ่มตัวจัดการบางอย่างเพื่อทำการเปลี่ยนแปลงบางอย่างเกี่ยวกับพฤติกรรม (ปรับเปลี่ยนแบบสอบถามบันทึกการวิเคราะห์ข้อมูลการกรองข้อมูลการกรองข้อมูลนวดภาพเคลื่อนไหว UI แฟนซีเชนสอบถามหลายลำดับ อะไรก็ตาม) ดังนั้นตัวจัดการบางตัวจะต้องถูกเรียกใช้ก่อน / หลังตัวจัดการบางตัวและพวกมันถูกลงทะเบียนจากจุดเข้าใช้ที่แตกต่างกันมากมายในแอปพลิเคชัน หลังจากผ่านไปครู่หนึ่งอาจเกิดขึ้นได้ที่ตัวจัดการโหลขึ้นไปมีการลงทะเบียนและการทำงานกับสิ่งนั้นอาจน่าเบื่อและอันตราย การออกแบบนี้เกิดขึ้นเนื่องจากการใช้การสืบทอดเริ่มเป็นระเบียบสมบูรณ์ ระบบเหตุการณ์ถูกนำมาใช้ในการประพันธ์ชนิดหนึ่งซึ่งคุณยังไม่รู้ว่าจะเป็นอย่างไร ในตอนท้ายของ ////////////// ดังนั้นฉันจึงสงสัยว่าคนอื่นกำลังจัดการกับรหัสประเภทนี้อย่างไร ทั้งเมื่อเขียนและอ่านแล้ว คุณมีวิธีการหรือเครื่องมือที่ช่วยให้คุณเขียนและรักษารหัสดังกล่าวโดยไม่เจ็บปวดมากหรือไม่?

1
ทำไม Protobuf 3 ทำให้ฟิลด์ทั้งหมดในข้อความเป็นตัวเลือก?
ไวยากรณ์ 3 ของ protobuf ทำให้ฟิลด์ทั้งหมดเป็นตัวเลือกที่ทิ้งคำหลักrequiredและoptionalจากไวยากรณ์ proto2 ก่อนหน้า อ่านความคิดเห็นจากนักพัฒนาดูเหมือนว่ามันทำเพื่อเพิ่มความเข้ากันได้ไบนารีไปข้างหน้า / ถอยหลัง แต่สำหรับฉันนั้นสามารถบังคับใช้ได้โดยเพียงแค่กำหนดชื่อแพคเกจพูดcom.example.messages.v1แล้วปล่อยให้ลูกค้าใช้ deserializers ที่พวกเขาเข้าใจ ในขณะเดียวกันก็ลบสัญญาบางฉบับที่ระบุว่าเป็นประเภทที่มีประโยชน์จากมุมมองด้านวิศวกรรมซอฟต์แวร์ เช่นถ้าฉันมี message Location { double latitude = 1; double longitude = 2; } ใน proto3 เป็นไปได้ที่จะสร้างการสำรองข้อมูลครึ่งหนึ่ง แต่ใช้ได้อย่างสมบูรณ์แบบLocationโดยไม่ได้ให้ข้อมูลหนึ่งในฟิลด์ที่จำเป็น นี่เป็นข้อเสียเปรียบครั้งใหญ่เมื่อสร้างรูปแบบการทำให้เป็นอนุกรมตามสคีมาสำหรับการแลกเปลี่ยนข้อมูลระหว่างลูกค้าหรือไม่ การย้ายรหัสตรวจสอบพิเศษเพิ่มเติมไปยังไคลเอนต์แต่ละรายไม่ได้แย่ไปกว่าการตรวจสอบว่าฟิลด์ที่จำเป็นทั้งหมดมีค่าที่ถูกต้องหรือไม่

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

1
โดยทั่วไปแล้วตัวจัดการเหตุการณ์ทำงานอย่างไร
นี่คือหัวข้อทั่วไป, ตัวจัดการเหตุการณ์ทำงานอย่างไร นี่หมายถึงเบื้องหลัง - จะเกิดอะไรขึ้นเมื่อสร้างขึ้น ฉันมีความคิดคร่าวๆ - แต่ต้องการที่จะได้รับการยืนยัน

2
ฉันจะจัดการกับผลข้างเคียงในการจัดหากิจกรรมได้อย่างไร
สมมติว่าเราต้องการใช้ระบบย่อยความปลอดภัยขนาดเล็กสำหรับแอปพลิเคชันทางการเงินที่เตือนผู้ใช้ทางอีเมลหากตรวจพบรูปแบบแปลก ๆ สำหรับตัวอย่างนี้รูปแบบจะประกอบด้วยสามธุรกรรมตามที่อธิบายไว้ ระบบย่อยความปลอดภัยสามารถอ่านเหตุการณ์จากระบบหลักจากคิว สิ่งที่ฉันต้องการได้รับคือการแจ้งเตือนที่เป็นผลโดยตรงจากเหตุการณ์ที่เกิดขึ้นในระบบโดยไม่มีการแสดงสื่อกลางที่เป็นแบบจำลองสถานะปัจจุบันของรูปแบบ เปิดใช้งานการตรวจสอบแล้ว ประมวลผลธุรกรรมแล้ว ประมวลผลธุรกรรมแล้ว ประมวลผลธุรกรรมแล้ว ทริกเกอร์แจ้งเตือน (id: 123) ส่งอีเมลเพื่อรับการแจ้งเตือน (สำหรับ id: 123) ประมวลผลธุรกรรมแล้ว เมื่อนึกถึงสิ่งนี้ฉันคิดว่าการจัดหากิจกรรมสามารถทำได้ที่นี่เป็นอย่างดีแม้ว่าฉันจะมีคำถามที่ไม่มีคำตอบที่ชัดเจน การแจ้งเตือนที่ทริกเกอร์ในตัวอย่างมีผลข้างเคียงที่ชัดเจนจำเป็นต้องส่งอีเมลสถานการณ์ที่ควรเกิดขึ้นเพียงครั้งเดียวเท่านั้น ดังนั้นจึงไม่ควรเกิดขึ้นเมื่อเล่นซ้ำเหตุการณ์ทั้งหมดของการรวมซ้ำ ในระดับหนึ่งฉันเห็นอีเมลที่ต้องส่งคล้ายกับการสร้างเนื้อหาที่สร้างขึ้นโดยฝ่ายแบบสอบถามที่ฉันเห็นมาหลายครั้งในวรรณกรรมการจัดหา CQRS / กิจกรรมด้วยความแตกต่างที่ไม่ลึกซึ้งนัก ในวรรณคดีนี้ด้านแบบสอบถามถูกสร้างขึ้นจากตัวจัดการเหตุการณ์ที่สามารถสร้างเป็นตัวเป็นตนของรัฐที่จุดที่กำหนดให้อ่านเหตุการณ์ทั้งหมดอีกครั้ง ในกรณีนี้แม้ว่าจะไม่สามารถบรรลุได้อย่างสมบูรณ์เช่นนั้นด้วยเหตุผลที่อธิบายไว้ก่อนหน้านี้ ความคิดที่ว่าทุกรัฐเป็นชั่วคราวใช้ไม่ได้เป็นอย่างดีที่นี่ เราต้องบันทึกความจริงที่ว่าการแจ้งเตือนถูกส่งไปที่ไหนสักแห่ง ทางออกที่ง่ายสำหรับฉันคือการมีตารางหรือโครงสร้างที่แตกต่างกันซึ่งคุณเก็บบันทึกการแจ้งเตือนที่ถูกเรียกใช้ก่อนหน้านี้ เนื่องจากเรามี ID เราจะสามารถตรวจสอบว่ามีการออกการแจ้งเตือนด้วย ID เดียวกันก่อนหน้านี้หรือไม่ การมีข้อมูลนี้จะทำให้ SendAlertCommand idempotent สามารถออกคำสั่งได้หลายคำสั่ง แต่ผลข้างเคียงจะเกิดขึ้นเพียงครั้งเดียว แม้จะมีวิธีแก้ปัญหานั้นในใจฉันก็ไม่รู้ว่านี่เป็นคำใบ้ว่ามีบางอย่างผิดปกติกับสถาปัตยกรรมนี้สำหรับปัญหานี้หรือไม่ วิธีการของฉันถูกต้องหรือไม่ มีสถานที่ใดบ้างที่ฉันสามารถค้นหาข้อมูลเพิ่มเติมเกี่ยวกับเรื่องนี้? มันแปลกที่ฉันไม่สามารถหาข้อมูลเพิ่มเติมเกี่ยวกับเรื่องนี้ได้ บางทีฉันอาจใช้ข้อความที่ไม่ถูกต้อง ขอบคุณมาก!

1
ฉันควรใช้คำสั่งหรือเหตุการณ์หรือไม่?
ความแตกต่างระหว่างคำสั่งและเหตุการณ์ในการสื่อสารรถบัสนั้นค่อนข้างคลุมเครือสำหรับฉัน ฉันรู้ว่าควรดำเนินการคำสั่งเพียงครั้งเดียวในขณะที่เหตุการณ์สามารถจัดการได้หลายครั้ง แต่ฉันก็ยังไม่แน่ใจว่าจะใช้คำสั่งหรือเหตุการณ์เมื่อใด ลองดูตัวอย่าง: เมื่อผู้ใช้ใหม่ลงทะเบียนกับเว็บแอปพลิเคชันเราควรสร้างบัญชีให้เขาและส่งอีเมลยืนยัน การสร้างบัญชี - นี่เป็นจุดที่เหมาะสมในการส่งCreateUserCommandรถบัสและให้ส่วนประกอบเฉพาะจัดการ หรือบางทีสิ่งนี้ไม่ควรนำมาใช้กับการสื่อสารบัสแบบอะซิงโครนัส? เราต้องการให้ผู้ใช้ ba สามารถล็อกอินเข้าสู่แอปพลิเคชันได้ทันที ด้วยรถบัสเราไม่รับประกันว่าคำสั่งจะถูกดำเนินการเมื่อใด การส่งอีเมล - หลังจากส่วนประกอบสร้างบัญชีฉันสามารถเห็นความเป็นไปได้ 2 อย่าง ส่งคำสั่งอื่นไปที่รถบัส SendConfirmationEmailCommand เผยแพร่กิจกรรม UserAccountCreatedEvent และปล่อยให้องค์ประกอบของผู้ส่งอีเมลคว้ามันและมันเป็นงาน ในอีกด้านหนึ่งฉันต้องการอีเมลยืนยันที่จะส่งเพียงครั้งเดียวเท่านั้น (ใช้คำสั่ง) ในทางกลับกันฉันเชื่อว่าอาจมีหลายองค์ประกอบที่สนใจในผู้ใช้ที่ลงทะเบียนใหม่ คนตัดไม้หรือผู้ส่ง SMS คุณจะใช้มันอย่างไร?

โดยการใช้ไซต์ของเรา หมายความว่าคุณได้อ่านและทำความเข้าใจนโยบายคุกกี้และนโยบายความเป็นส่วนตัวของเราแล้ว
Licensed under cc by-sa 3.0 with attribution required.