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

ผมอ่าน เว็บไซต์ของ JDOM ทำไม JDOM API จึงถูกกำหนดในรูปแบบของคลาสที่เป็นรูปธรรมมากกว่าส่วนต่อประสาน? Jason Hunter สรุปข้อโต้แย้งกับ API ที่ใช้อินเตอร์เฟสสำหรับ JDOM: ด้วยอินเทอร์เฟซทุกอย่างกลายเป็นโรงงานองค์ประกอบจะต้อง 'นำเข้า' ลงในเอกสารใหม่แทนที่จะเพิ่มเพียงอย่างเดียวจึงไม่สามารถรับประกันคุณสมบัติเช่นการทำให้เป็นอนุกรมในระยะยาวและรายการจะดำเนินต่อไป เราเริ่มต้นด้วยอินเตอร์เฟสจริง ๆ แล้ว ในระหว่างการตรวจสอบก่อนเผยแพร่ของเรากับเพื่อนบางคนเราได้รับข้อเสนอแนะเราควรลองคลาสที่เป็นรูปธรรม เราทำและการออกแบบก็ดีกว่ามาก ฉันเป็นนักออกแบบมือใหม่ คำแนะนำทั้งหมดที่ฉันเคยได้ยินจนถึงขณะนี้คือการต่อต้านการใช้การออกแบบด้วยชั้นเรียนที่เป็นรูปธรรม อาจจะใช้คลาสคอนกรีตที่เหมาะสมในบางสถานที่ มีปัญหาของคลาสทั่วไปที่ใช้คลาสคอนกรีตในการออกแบบไม่เป็นไร

10 java  design  object-oriented  architectural-patterns 

ข้อมูลจำเพาะ JWT อธิบายถึงน้ำหนักบรรทุกและวิธีการส่ง แต่ปล่อยให้โปรโตคอลการตรวจสอบความถูกต้องเปิดซึ่งช่วยให้มีความยืดหยุ่น แต่น่าเสียดายที่ความยืดหยุ่นสามารถนำไปสู่การออกแบบและออกแบบที่ผิด ฉันกำลังมองหาแนวคิดที่ดีและผ่านการทดสอบการใช้งานองค์กรสำหรับการรับรองความถูกต้อง JWT ซึ่งฉันสามารถใช้หรือปรับเปลี่ยนได้ แต่ฉันล้มเหลวในการค้นหาสิ่งที่สมบูรณ์ สิ่งที่ฉันคิดคือ เมื่อไม่พบส่วนหัวการให้สิทธิ์หรือโทเค็น JWT ไม่ถูกต้องหรือหมดอายุให้ส่ง HTTP 401 เพื่อตรวจสอบสิทธิ์ใช้ / ล็อกอินช่อง REST ส่งชื่อผู้ใช้และรหัสผ่านเป็นวัตถุ JSON เพื่อให้โทเค็นยังมีชีวิตอยู่ใช้ / keepalive REST ช่องเรียกมันทุก ๆ N (5) นาทีรับโทเค็น JWT ใหม่และแทนที่หนึ่งที่มีอยู่หลังจากแต่ละสาย (โทเค็นหมดอายุหลังจาก M (15) นาที) อย่างไรก็ตามสิ่งที่รบกวนฉันคือความจำเป็นของช่องทางนั้น / keepalive ในทางกลับกันมันบังคับให้ฉันเพื่อป้องกันไม่ให้การรับรองความถูกต้องหมดอายุแม้ว่าผู้ใช้จะไม่อยู่ (การตัดสินใจถ้าเรายังต้องการ keepalive ยังไม่พบ) และแน่นอนการโทรเหล่านั้นเป็นพิเศษและมีความซับซ้อนเป็นพิเศษในโปรโตคอล สิ่งที่น่าสนใจก็คือเซิร์ฟเวอร์นั้นจะขยายโทเค็นโดยอัตโนมัติ ในสภาพแวดล้อมแบบเซสชันนั้นเกิดขึ้นโดยการรีเซ็ตเวลาประทับที่นี่อย่างไรก็ตามเซิร์ฟเวอร์จะต้องส่งโทเค็นใหม่อาจไม่ได้แต่ละครั้ง แต่เมื่อโทเค็นจะหมดอายุใน R (พูด 10 …

9 rest  authentication  architectural-patterns 

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

9 design-patterns  architecture  event-programming  architectural-patterns  event-sourcing 

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

9 design  functional-programming  haskell  architectural-patterns