คำถามติดแท็ก design-patterns

ฉันพยายามที่จะเข้าใจความแตกต่างระหว่างหลักการเปิด (OCP) และหลักการผกผันของการพึ่งพา (DIP) จากการวิจัยที่ฉันได้ทำบนอินเทอร์เน็ตจนถึงตอนนี้ฉันได้ข้อสรุปว่า 'DIP เป็นทางเลือกหนึ่งที่เราสามารถบรรลุ OCP' ฉันถูกใช่ไหม คุณสามารถยกตัวอย่างที่ไม่ทำตามกรมทรัพย์สินทางปัญญา แต่ติดตาม OCP ได้ไหม

12 design-patterns  object-oriented  object-oriented-design  solid 

ฉันยังใหม่กับการฉีดแบบพึ่งพาและฉันมีคำถามสองสามข้อเกี่ยวกับสไตล์ที่ฉันควรใช้ในแอปพลิเคชันของฉัน ฉันเพิ่งอ่านInversion of Control Containers และรูปแบบการพึ่งพาการฉีดของ Martin Fowler แต่ฉันไม่สามารถรับความแตกต่างระหว่าง Constructor, Setter และ Interface Injection ได้ สำหรับฉันแล้วเหตุผลที่ใช้อีกอันหนึ่งเป็นเพียงเรื่องของการล้างโค้ดและ / หรือความชัดเจน อะไรคือความแตกต่าง? มีข้อดีหรือข้อเสียที่แข็งแกร่งในการใช้อย่างใดอย่างหนึ่งมากกว่าหรือเป็นเพียงสิ่งที่ฉันได้กล่าวก่อนหน้านี้? ในความคิดของการฉีดคอนสตรัคเป็นที่ใช้งานง่ายที่สุดของทั้งหมดเช่นเดียวกับการฉีดอินเตอร์เฟซเป็นอย่างน้อย ในอีกทางหนึ่งการฉีดเซทเทอร์เป็นระยะกลาง แต่คุณควรจะสามารถเปลี่ยนอินสแตนซ์ของออบเจ็กต์การพึ่งพาที่คุณฉีดตอนแรกได้หรือไม่ รูปแบบการฉีดแบบนี้รับประกันได้ว่าวัตถุที่ต้องการการพึ่งพานั้นจะต้องทำการฉีดหรือไม่? ฉันไม่เชื่อ แต่โปรดแก้ไขให้ถูกต้องถ้าฉันผิด

12 design-patterns  dependency-injection  inversion-of-control 

ฉันอยู่ในขั้นตอนการออกแบบ HTTP API หวังว่าจะทำให้ RESTful ที่สุดเท่าที่จะทำได้ มีการกระทำบางอย่างที่ฟังก์ชันการทำงานกระจายไปทั่วทรัพยากรบางอย่างและบางครั้งจำเป็นต้องเลิกทำ ฉันคิดกับตัวเองเสียงนี้ดูเหมือนรูปแบบคำสั่ง แต่ฉันจะสร้างแบบจำลองเป็นทรัพยากรได้อย่างไร ฉันจะแนะนำทรัพยากรใหม่ชื่อ XXAction เช่น DepositAction ซึ่งจะถูกสร้างขึ้นผ่านบางสิ่งเช่นนี้ POST /card/{card-id}/account/{account-id}/Deposit AmountToDeposit=100, different parameters... สิ่งนี้จะสร้าง DepositAction ใหม่และเปิดใช้งานวิธีการ Do / Execute ในกรณีนี้การส่งคืนสถานะ HTTP ที่สร้าง 201 หมายถึงการดำเนินการถูกดำเนินการสำเร็จ หลังจากนั้นหากลูกค้าต้องการดูรายละเอียดการกระทำที่เขาสามารถทำได้ GET /action/{action-id} ควรปิดกั้นการอัปเดต / วางเพราะฉันไม่เกี่ยวข้องที่นี่ และเพื่อเลิกทำการกระทำฉันคิดถึงการใช้ DELETE /action/{action-id} ซึ่งจริงๆแล้วจะเรียกวิธีการเลิกทำของวัตถุที่เกี่ยวข้องและเปลี่ยนสถานะเป็น สมมติว่าฉันมีความสุขกับสิ่งเดียวที่ต้องเลิกทำฉันไม่จำเป็นต้องทำซ้ำ วิธีนี้ใช้ได้หรือไม่ มีข้อผิดพลาดใด ๆ เหตุผลที่จะไม่ใช้มัน? สิ่งนี้เป็นที่เข้าใจจาก POV ของลูกค้าหรือไม่

12 design-patterns  api  rest  api-design  http 

เมื่อเร็ว ๆ นี้มีการปฏิวัติต่อต้านซิงเกิลบ้าง แต่มีอะไรผิดปกติกับพวกเขาไหมถ้าพวกเขาไร้สัญชาติ? ฉันรู้ว่าการพูดคุยที่มากเกินไปและทั้งหมด ... สิ่งนี้ใช้ได้กับทุกสิ่งที่ไม่ใช่แค่ซิงเกิลตัน

12 design-patterns  object-oriented  singleton  immutability 

ฉันกำลังพัฒนาแอพที่จะใช้ในการเปิดและปิดวาล์วในสภาพแวดล้อมอุตสาหกรรมและกำลังคิดถึงบางสิ่งที่เรียบง่ายเช่นนี้: - public static void ValveController { public static void OpenValve(string valveName) { // Implementation to open the valve } public static void CloseValve(string valveName) { // Implementation to close the valve } } (การนำไปใช้นั้นจะเขียนข้อมูลสองสามไบต์ไปยังพอร์ตอนุกรมเพื่อควบคุมวาล์ว - "ที่อยู่" ซึ่งได้มาจากชื่อของวาล์วและ "1" หรือ "0" เพื่อเปิดหรือปิดวาล์ว) นักพัฒนาอีกคนถามว่าเราควรสร้างคลาสแยกต่างหากสำหรับแต่ละวาล์วทางกายภาพซึ่งมีอยู่เป็นสิบหรือไม่ ฉันยอมรับว่ามันจะดีกว่าที่จะเขียนโค้ดเหมือนPlasmaValve.Open()มากกว่าValveController.OpenValve("plasma")แต่นี่เป็น overkill หรือไม่ นอกจากนี้ฉันยังสงสัยว่าวิธีที่ดีที่สุดในการจัดการกับการออกแบบโดยคำนึงถึงความต้องการในอนาคตของสมมุติสองสามข้อ: - เราได้รับการร้องขอให้สนับสนุนวาล์วชนิดใหม่ที่ต้องการค่าต่าง ๆ …

12 design  design-patterns  object-oriented 

เป็นการยากที่จะบอกสิ่งที่ถูกถามที่นี่ คำถามนี้คลุมเครือคลุมเครือไม่สมบูรณ์กว้างเกินไปหรือโวหารและไม่สามารถตอบได้อย่างสมเหตุสมผลในรูปแบบปัจจุบัน สำหรับความช่วยเหลือในการทำความเข้าใจคำถามนี้เพื่อที่จะสามารถเปิด, ไปที่ศูนย์ช่วยเหลือ ปิดให้บริการใน7 ปีที่ผ่านมา ฉันเห็นที่นี่ในโปรแกรมเมอร์คำตอบสำหรับคำถามนี้: การคิดเกี่ยวกับรูปแบบการออกแบบและการปฏิบัติของ OOP เปลี่ยนไปอย่างไรในภาษาที่มีการเปลี่ยนแปลงและมีชีวิตชีวา มีผมพบว่าเชื่อมโยงไปยังบทความที่มีชื่อตรงไปตรงมา: รูปแบบการออกแบบที่ขาดหายไปคุณสมบัติภาษา แต่ที่ฉันพบตัวอย่างที่ฉันดูเหมือนลวงมากและที่สามารถตรวจสอบกับประสบการณ์ที่ได้รับมีสิ่งจูงใจเช่น: PaulGraham กล่าวว่า "Peter Norvig พบว่า 16 จาก 23 รูปแบบในรูปแบบการออกแบบนั้น 'มองไม่เห็นหรือเรียบง่าย' ใน Lisp" หรือประโยคอื่นที่ยืนยันสิ่งที่ฉันเห็นเมื่อเร็ว ๆ นี้กับผู้ที่พยายามจำลองชั้นเรียนใน JavaScript: แน่นอนว่าไม่มีใครเคยพูดถึงรูปแบบ "ฟังก์ชั่น" หรือรูปแบบ "ชั้นเรียน" หรือสิ่งอื่น ๆ อีกมากมายที่เราให้สิทธิ์เพราะภาษาส่วนใหญ่ให้พวกเขาเป็นคุณสมบัติในตัว OTOH โปรแกรมเมอร์ในภาษา PrototypeOrientedLanguage หรือไม่? อาจสะดวกในการจำลองคลาสด้วยต้นแบบ ... นอกจากนี้ผมยังคำนึงถึงว่ารูปแบบการออกแบบเป็นเครื่องมือติดต่อสื่อสาร เพราะแม้จะมีประสบการณ์ จำกัด ในการสร้างแอปพลิเคชันฉันก็สามารถเห็นได้ว่าเป็นรูปแบบการต่อต้าน ( ไม่มีประสิทธิภาพและ / หรือการต่อต้าน …

12 programming-languages  design-patterns 

Persistence Ignoranceเป็นแอพพลิเคชั่นของหลักการความรับผิดชอบเดี่ยวซึ่งในทางปฏิบัติหมายความว่า Domain Objects ( DO ) ไม่ควรมีรหัสที่เกี่ยวข้องกับการคงอยู่ แต่ควรจะมีตรรกะของโดเมนเท่านั้น a) ฉันถือว่านี่หมายความว่ารหัสที่ติดต่อเลเยอร์ที่ต่ำกว่า (เช่นชั้นที่มีอยู่) อยู่นอกโมเดลโดเมนในคลาสอื่น ( OC ) ของเลเยอร์ตรรกะทางธุรกิจหรือไม่ b) หากการสันนิษฐานของฉันภายใต้a)ถูกต้องดังนั้นDOพูดว่าCustomerไม่มีวิธีการเช่นGetCustomersหรือGetCustomerByID? c) หากสมมุติฐานของฉันภายใต้a)และb)ถูกต้องและสมมติว่าCustomerวัตถุโดเมนใช้การโหลดแบบขี้เกียจสำหรับคุณสมบัติบางอย่างนั้นCustomerตรรกะภายในของบางจุดจะต้องติดต่อOCซึ่งจะดึงข้อมูลที่ได้รับการแก้ไข แต่ถ้าCustomerต้องการติดต่อOCเพื่อรับข้อมูลที่ถูกหักล้างเราไม่สามารถอ้างสิทธิ์ได้จริงๆว่า Domain Objects ไม่มีตรรกะที่เกี่ยวข้องกับการคงอยู่หรือไม่! ขอบคุณ ตอบกลับไปยัง jkohlhepp 1) ผมถือว่าOrderProviderและCustomerProviderชั้นเรียนที่มีอยู่ภายในชั้นตรรกะทางธุรกิจ? 2) ฉันรวบรวมจากคำตอบของคุณว่าสมมติฐานของฉันภายใต้ข)ถูกต้องหรือไม่ 3) ... ฉันจะตรวจสอบเพื่อดูว่าฟิลด์คำสั่งซื้อส่วนตัวบางส่วนมีการเติมข้อมูลหรือไม่หรือไม่ ถ้ามันเป็นโมฆะ ... แต่เท่าที่ฉันสามารถบอกได้ทันทีที่รหัสโดเมนจำเป็นต้องตรวจสอบว่าorderมีการเติมข้อมูลในฟิลด์ส่วนตัวหรือไม่และถ้าไม่ติดต่อ OrderProvider เรากำลังละเมิดหลักการPIอยู่แล้ว!

12 design-patterns  domain-driven-design  domain-model  persistence 

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

12 design-patterns  database-design 

Wikipedia พูดว่า "เอนทิตีของซอฟต์แวร์ (คลาส, โมดูล, ฟังก์ชั่น, ฯลฯ ) ควรเปิดเพื่อขยาย แต่ปิดเพื่อแก้ไข" ฟังก์ชั่นคำดึงดูดสายตาของฉันและตอนนี้ฉันสงสัยว่าเราสามารถสันนิษฐานได้ว่าการสร้างเกินพิกัดสำหรับวิธีการสามารถถือได้ว่าเป็นตัวอย่างของหลักการเปิด / ปิดหรือไม่? ให้ฉันอธิบายตัวอย่าง พิจารณาว่าคุณมีวิธีการในชั้นบริการซึ่งใช้ในสถานที่เกือบ 1,000 แห่ง วิธีการได้รับ userId และกำหนดว่าผู้ใช้เป็นผู้ดูแลหรือไม่: bool IsAdmin(userId) ตอนนี้ให้พิจารณาว่ามีบางสิ่งที่จำเป็นในการพิจารณาว่าผู้ใช้เป็นผู้ดูแลระบบหรือไม่โดยยึดตามชื่อผู้ใช้ไม่ใช่ชื่อผู้ใช้ หากเราเปลี่ยนลายเซ็นของวิธีการที่กล่าวถึงข้างต้นแสดงว่าเรามีรหัสที่ไม่สมบูรณ์ใน 1000 แห่ง (ฟังก์ชั่นควรปิดเพื่อแก้ไข) ดังนั้นเราสามารถสร้างโอเวอร์โหลดเพื่อรับชื่อผู้ใช้ค้นหา userId ตามชื่อผู้ใช้และวิธีการดั้งเดิม: public bool IsAdmin(string username) { int userId = UserManager.GetUser(username).Id; return IsAdmin(userId); } ด้วยวิธีนี้เราได้ขยายฟังก์ชั่นของเราผ่านการสร้างโอเวอร์โหลด (ฟังก์ชั่นควรจะเปิดเพื่อขยาย) มันเป็นตัวอย่างหลักการเปิด / ปิดหรือไม่?

12 solid  design-patterns  open-close 

ตามที่เป็นอยู่ในปัจจุบันคำถามนี้ไม่เหมาะสำหรับรูปแบบคำถาม & คำตอบของเรา เราคาดหวังคำตอบที่จะได้รับการสนับสนุนจากข้อเท็จจริงการอ้างอิงหรือความเชี่ยวชาญ แต่คำถามนี้มีแนวโน้มที่จะเรียกร้องให้มีการอภิปรายโต้แย้งโต้แย้งหรือการอภิปรายเพิ่มเติม หากคุณรู้สึกว่าคำถามนี้สามารถปรับปรุงและเปิดใหม่ได้โปรดไปที่ศูนย์ช่วยเหลือเพื่อขอคำแนะนำ ปิดให้บริการใน8 ปีที่ผ่านมา ฉันสารภาพ : ฉันมีปัญหาในการ "ทำให้มันง่ายและสั้น" เกือบตลอดเวลาเพราะพยายามทำตามหนังสือที่ฉันอ่านรูปแบบการออกแบบที่ฉันเคยได้ยิน ฯลฯ ทำให้ฉันมีความกระตือรือร้น - ความกระตือรือร้นมาจาก ความรู้สึกว่าฉันอยู่บนเส้นทางที่ถูกต้องไปสู่ความสมบูรณ์แบบที่เป็นไปได้ ในทางตรงกันข้ามใช่มันทำให้ฉันเครียดเป็นพิเศษในแง่ของการส่งมอบกำหนดเวลาบางครั้ง ... แต่เมื่อใดก็ตามที่ฉันพูดกับตัวเองว่า "ครั้งต่อไปทำให้มันง่ายคุณโง่!" ฉันคิดว่ามันเงียบยากที่จะทำให้มัน "เรียบง่าย" ในครั้งต่อไปที่มาเพราะมันเริ่มรู้สึกแปลก ๆ ... และอึดอัดหลังจากจุดหนึ่ง จากนั้นฉันก็เริ่มที่จะตัดสินความเข้าใจของฉัน 'ง่าย' ... SIMPLE หมายถึงสั้นเกินไปที่จะใช้งานได้ แต่ยากที่จะรักษาและขยายออกไป? SIMPLE หมายถึงการทำลายหลักการ OOP มากมายหรือไม่? SIMPLE หมายถึงการโกงหรือไม่ SIMPLE หมายถึงเพียงแค่รักษากำหนดเวลาโดยไม่ต้องไม่มี dealy หรือไม่? เป็นต้น จริงๆแล้วมันคืออะไร คำถามคือ : คุณสามารถเขียนคำจำกัดความที่แน่นอนของ SIMPLE …

12 design-patterns 

จนถึงตอนนี้ฉันเป็นแฟนตัวยงของรูปแบบ MVC สำหรับการพัฒนาเว็บแอปพลิเคชัน สำหรับเว็บฉันได้พัฒนาส่วนใหญ่ใน PHP (ด้วยกรอบ Kohana และ CodeIgniter) และ Ruby (RoR) เมื่อแอพพลิเคชั่นของฉันหนักกว่าด้านอาแจ็กซ์ (แอพพลิเคชั่นหน้าเดียว ฯลฯ ) ฉันสังเกตเห็นว่าฉันอดไม่ได้ที่จะทรยศต่อแนวคิดพื้นฐานที่สำคัญของ MVC: Javascript ทำงานส่วนใหญ่ การเรียกตัวควบคุมเพื่อขอดูหรือมากกว่ารหัส js / json ดูเหมือนผิด หลังจากพยายามรักษางานการเราต์ทั้งหมดไว้ในคอนโทรลเลอร์ตอนนี้ฉันได้แยกมันระหว่างพวกเขาและ Javascript (นั่นคือจาก PoV ของเฟรมเวิร์กเป็นส่วนหนึ่งของมุมมอง) เมื่อขอ json การโค่นล้ม MVC ดูชัดเจนยิ่งขึ้น: รหัส js ที่ทำการร้องขอคือคอนโทรลเลอร์; คอนโทรลเลอร์ของเฟรมเวิร์กทำหน้าที่เป็นพร็อกซีสำหรับข้อมูลของโมเดลซึ่งเป็นสิ่งที่ฉันต้องการ ดังนั้นฉันควรตรวจสอบอะไร ฉันกำลังคิดเกี่ยวกับแอปพลิเคชัน pure-javascript เช่น backbone.js และฐานข้อมูล json-spitting (couchDB) ที่ใช้เอกสารเป็นแบ็กเอนด์ แต่ฉันรักฐานข้อมูลเชิงสัมพันธ์ของฉัน ตัวเลือกอื่นจะเป็นดังต่อไปนี้: …

12 javascript  design-patterns  mvc  ajax 

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

12 design-patterns  language-agnostic 

ย้อนกลับไปในปีพ. ศ. 2550 ฉันอ่านบทความเกี่ยวกับ Joshua Blochs เกี่ยวกับ "รูปแบบการสร้าง" และวิธีที่จะสามารถแก้ไขเพื่อปรับปรุงการใช้ตัวสร้างและตัวตั้งค่ามากเกินไปโดยเฉพาะอย่างยิ่งเมื่อวัตถุมีคุณสมบัติจำนวนมากซึ่งส่วนใหญ่เป็นทางเลือก สรุปโดยย่อของรูปแบบการออกแบบนี้จะฝึกหัดที่นี่ ฉันชอบแนวคิดนี้และใช้มันตั้งแต่ ปัญหากับมันในขณะที่มันสะอาดและดีที่จะใช้จากมุมมองของลูกค้าการใช้มันอาจเป็นความเจ็บปวดในก้น! มีสถานที่แตกต่างกันมากมายในวัตถุที่มีการอ้างอิงคุณสมบัติเดียวและทำให้การสร้างวัตถุและการเพิ่มคุณสมบัติใหม่ใช้เวลานาน ดังนั้น ... ฉันมีความคิด ก่อนวัตถุตัวอย่างในสไตล์ของ Joshua Bloch: สไตล์ Josh Bloch: public class OptionsJoshBlochStyle { private final String option1; private final int option2; // ...other options here <<<< public String getOption1() { return option1; } public int getOption2() { …

12 java  design-patterns 

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

12 c++  design  design-patterns 

ฉันกำลังตั้งค่าบริการเว็บสงบใหม่และฉันต้องการให้แบบจำลองการควบคุมการเข้าถึงตามบทบาท ฉันต้องสร้างสถาปัตยกรรมที่อนุญาตให้ผู้ใช้ระบุชื่อผู้ใช้และรหัสผ่านเพื่อเข้าถึงบริการและ จำกัด วิธีการใช้บริการ (บริการใดบ้างที่พวกเขาสามารถใช้อ่าน vs อ่าน / เขียน ฯลฯ ) ตามบทบาท มอบหมายให้กับผู้ใช้นั้น ฉันได้ดูคำถามอื่น ๆ และพบสิ่งที่ฉันต้องการ ตัวอย่างเช่นมีการอภิปรายที่ดีหลายประการเกี่ยวกับวิธีการจัดการข้อมูลประจำตัวที่ผ่านการบริการที่ REST พักผ่อนสบายตลอดการตรวจสอบ , การปฏิบัติที่ดีที่สุด นอกจากนี้ยังมีตัวชี้ที่ยอดเยี่ยมเกี่ยวกับสิ่งที่โปรแกรมเมอร์ควรรู้เมื่อสร้างเว็บไซต์ ( สิ่งที่นักพัฒนาทุกคนควรรู้ก่อนสร้างเว็บไซต์สาธารณะ ) แต่ฉันไม่สามารถค้นหาบทความบทความหนังสือเกี่ยวกับแนวปฏิบัติและรูปแบบที่ดีสำหรับสถาปัตยกรรมซอฟต์แวร์ที่ใช้โซลูชันเหล่านี้ โดยเฉพาะ: ควรจัดเก็บรายละเอียดผู้ใช้และสิทธิ์การเข้าถึงอย่างไร (ตัวแบบข้อมูล, สถานที่, รูปแบบ) รูปแบบการออกแบบที่ดีสำหรับการแสดงและติดตามสิ่งเหล่านี้ในเซิร์ฟเวอร์มีอะไรบ้าง (เซสชันในหน่วยความจำการค้นหาฐานข้อมูลในแต่ละครั้ง ฯลฯ ) อะไรคือรูปแบบที่ดีสำหรับการจับคู่สิทธิเหล่านี้กับบริการในวิธีที่ปลอดภัยในรหัสฐาน ตัวเลือกสถาปัตยกรรมใดบ้างที่สามารถช่วยให้ระบบปลอดภัยและเชื่อถือได้มากขึ้น ผู้เรียนมีบทเรียนอะไรบ้างจากสนามเพลาะ? ฉันกำลังมองหารูปแบบการออกแบบและคำแนะนำสำหรับสถาปัตยกรรมซอฟต์แวร์นอกเทคโนโลยีเฉพาะใด ๆ (หากเทคโนโลยีมีความสำคัญฉันกำลังวางแผนที่จะใช้สิ่งนี้โดยใช้ python, twisted, และฐานข้อมูล postgresql)

12 web-development  design-patterns  security  web-services  rest