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

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

85 design-patterns 

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

85 design-patterns  architecture  domain-driven-design  presentation-layer  data-transfer-objects 

ฉันกำลังคิดหาวิธีที่ดีที่สุดในการออกแบบระบบรางวัลพิเศษสำหรับใช้บนไซต์ของฉัน โครงสร้างฐานข้อมูลสามารถพบได้ในวิธีที่ดีที่สุดในการบอกระเบียนติดต่อกัน 3 รายการขึ้นไปที่ขาดหายไปและเธรดนี้เป็นส่วนเสริมในการรับแนวคิดจากนักพัฒนา ปัญหาที่ฉันมีจากการพูดคุยมากมายเกี่ยวกับระบบตรา / รางวัลพิเศษบนเว็บไซต์นี้มีเพียงแค่นั้น - ทั้งหมดนี้เป็นการพูดคุยและไม่มีรหัส ตัวอย่างการติดตั้งโค้ดจริงอยู่ที่ไหน ฉันเสนอการออกแบบที่ฉันหวังว่าผู้คนจะมีส่วนร่วมและหวังว่าจะสร้างการออกแบบที่ดีสำหรับการเข้ารหัสระบบความสำเร็จที่ขยายได้ ฉันไม่ได้บอกว่านี่เป็นสิ่งที่ดีที่สุดไกลจากมัน แต่มันเป็นช่วงเริ่มต้นที่เป็นไปได้ โปรดอย่าลังเลที่จะให้ความคิดของคุณ แนวคิดการออกแบบระบบของฉัน ดูเหมือนว่าฉันทามติทั่วไปคือการสร้าง "ระบบตามเหตุการณ์" - เมื่อใดก็ตามที่เหตุการณ์ที่ทราบเกิดขึ้นเช่นมีการสร้างโพสต์ลบ ฯลฯ จะเรียกคลาสเหตุการณ์เช่นนั้น .. $event->trigger('POST_CREATED', array('id' => 8)); จากนั้นคลาสกิจกรรมจะค้นหาว่าป้ายใด "กำลังฟัง" สำหรับกิจกรรมนี้จากนั้นจึงเป็นrequiresไฟล์นั้นและสร้างอินสแตนซ์ของคลาสนั้นดังนี้: require '/badges/' . $file; $badge = new $class; จากนั้นจะเรียกเหตุการณ์เริ่มต้นที่ส่งผ่านข้อมูลที่ได้รับเมื่อtriggerถูกเรียก $badge->default_event($data); ป้าย นี่คือที่ที่เวทมนตร์ที่แท้จริงเกิดขึ้น ป้ายแต่ละป้ายมีคำถาม / ตรรกะของตัวเองเพื่อพิจารณาว่าควรได้รับป้ายหรือไม่ แต่ละป้ายกำหนดไว้ในรูปแบบเช่นนี้: class Badge_Name extends Badge { …

85 php  mysql  database  design-patterns 

ฉันกำลังสร้างแอป Laravel ซึ่งมีคุณสมบัติหลายอย่าง ฉันต้องการที่จะเปิดใช้งานหรือปิดการใช้งานพวกเขาขึ้นอยู่กับความต้องการของโดเมนที่เฉพาะเจาะจง ขณะนี้ฉันมีชุดธงหลายรายการเช่น: 'is_feature_1_enabled' => true, 'is_feature_2_enabled' => false, ... และต่อไป จากนั้นในตัวควบคุมและมุมมองของฉันฉันตรวจสอบค่ากำหนดเหล่านั้นเพื่อดูว่าฉันควรจะแสดงบางสิ่งบางอย่างหรือไม่อนุญาตให้ดำเนินการบางอย่าง ฯลฯ แอปของฉันเริ่มที่จะได้รับมลพิษด้วยการตรวจสอบเหล่านี้ทุกที่ มีวิธีปฏิบัติที่ดีที่สุดในการจัดการคุณสมบัติในแอป Laravel หรือไม่?

10 laravel  laravel-5  design-patterns  laravel-4