คำถามติดแท็ก architecture

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

3
วิธีสร้างเว็บแอปพลิเคชั่นแบบแยกส่วนอย่างสมบูรณ์ [ปิด]
ในอีกไม่กี่เดือนข้างหน้าเราจะเริ่มโครงการที่เราใช้ระบบที่เราสร้างขึ้นเพื่อลูกค้า (v1) และสร้างใหม่โดยเริ่มจากศูนย์ เป้าหมายของเรากับ v2 คือการทำให้เป็นแบบแยกส่วนเพื่อให้ลูกค้าเฉพาะรายนี้จะมีชุดโมดูลของตนเองที่ใช้จากนั้นลูกค้ารายอื่นอาจใช้ชุดโมดูลที่แตกต่างกันโดยสิ้นเชิง เคล็ดลับที่นี่คือ บริษัท A อาจมีชุดการชำระเงินและโมดูลผู้ใช้ที่เปลี่ยนวิธีการทำงานของระบบ บริษัท B อาจยึดตามขั้นตอนการชำระเงินมาตรฐาน แต่กำหนดวิธีการเรียกดูผลิตภัณฑ์ อะไรคือวิธีที่ดีในสถาปัตยกรรมแอปพลิเคชันเมื่อคุณสร้างแอปพลิเคชันตั้งแต่เริ่มต้นที่คุณต้องการให้มีการCoreใช้ร่วมกันในหมู่ลูกค้าทั้งหมดในขณะที่ยังคงความยืดหยุ่นสำหรับสิ่งที่จะแก้ไขโดยเฉพาะสำหรับลูกค้า? ฉันเคยเห็น hooks ของ CodeIgniter และไม่คิดว่ามันเป็นทางออกที่ดีเพราะเราสามารถจบได้ด้วย 250 hooks และมันยังไม่ยืดหยุ่นพอ โซลูชั่นอื่น ๆ มีอะไรบ้าง เป็นการดีที่เราไม่จำเป็นต้องลากเส้นในทราย

8
วิธีที่ดีที่สุดในการออกแบบเว็บไซต์ให้มีความยืดหยุ่นสูงคืออะไร?
สำหรับเว็บไซต์ที่ต้องปรับขนาดได้สูงเช่นเครือข่ายสังคมออนไลน์อย่าง facebook วิธีที่ดีที่สุดในการออกแบบเว็บไซต์คืออะไร ฉันควรมีบริการเว็บที่เว็บไซต์สอบถามเพื่อรับข้อมูลที่ต้องการหรือไม่ หรือ ควรสอบถามฐานข้อมูลเว็บไซต์โดยตรงหรือไม่ (สามารถทำได้โดยใช้ built-in สร้างภาษาเพื่อเติมตารางอัตโนมัติ ฯลฯ ) ฉันคิดว่าบริการเว็บเป็นการออกแบบที่ดีกว่าเนื่องจากให้การเข้าถึงข้อมูลจากส่วนกลางและสิ่งต่าง ๆ เช่นแคชและสิ่งที่คล้ายกันนั้นควบคุมได้ง่ายกว่า แต่คนอื่น ๆ คิดอย่างไร

5
Microservices และขั้นตอนการจัดเก็บ
กระบวนงานที่เก็บไว้ถูกพิจารณาว่าเป็นการปฏิบัติที่ไม่ดีในสถาปัตยกรรม microservice หรือไม่ นี่คือความคิดของฉัน: หนังสือส่วนใหญ่ใน microservices แนะนำหนึ่งฐานข้อมูลต่อ microservice ขั้นตอนการจัดเก็บมักจะทำงานบนฐานข้อมูลเสาหิน อีกครั้งหนังสือสถาปัตยกรรมไมโครบริการส่วนใหญ่ระบุว่าพวกเขาควรจะเป็นอิสระและควบคู่กันอย่างอิสระ การใช้ขั้นตอนการจัดเก็บที่เขียนไว้พูดเฉพาะใน Oracle คู่หูกับบริการไมโครสโคปกับเทคโนโลยีนั้นอย่างแน่นหนา หนังสือสถาปัตยกรรม microservice ส่วนใหญ่ (ที่ฉันได้อ่าน) แนะนำว่า microservices ควรเป็นเชิงธุรกิจ (ออกแบบโดยใช้การออกแบบที่ขับเคลื่อนด้วยโดเมน (DDD)) โดยการย้ายตรรกะทางธุรกิจไปยังกระบวนงานที่เก็บไว้ในฐานข้อมูลจะไม่เป็นเช่นนั้นอีกต่อไป ความคิดใด ๆ เกี่ยวกับเรื่องนี้?

5
คุณควรใส่ค่าคงที่ตรงไหนและทำไม?
ในแอปพลิเคชันขนาดใหญ่ส่วนใหญ่ของเราเรามักจะมีเพียงไม่กี่ตำแหน่งสำหรับ "ค่าคงที่": หนึ่งคลาสสำหรับ GUI และค่าคงที่ภายใน (ชื่อแท็บหน้า, ชื่อกลุ่มกล่อง, ปัจจัยการคำนวณ, การแจกแจง) หนึ่งคลาสสำหรับตารางและคอลัมน์ฐานข้อมูล (ส่วนนี้เป็นรหัสที่สร้างขึ้น) พร้อมชื่อที่อ่านได้สำหรับพวกเขา (กำหนดด้วยตนเอง) คลาสหนึ่งสำหรับข้อความแอปพลิเคชัน (การบันทึกกล่องข้อความ ฯลฯ ) ค่าคงที่มักจะถูกแยกออกเป็นส่วนต่าง ๆ ในคลาสเหล่านั้น ในแอปพลิเคชัน C ++ ของเราค่าคงที่จะถูกกำหนดเฉพาะในไฟล์. h และค่าจะถูกกำหนดในไฟล์. cpp ข้อดีอย่างหนึ่งก็คือสตริงทั้งหมด ฯลฯ อยู่ในจุดศูนย์กลางเดียวและทุกคนรู้ว่าจะต้องค้นหาสิ่งใดเมื่อต้องมีการเปลี่ยนแปลง นี่เป็นสิ่งที่ผู้จัดการโครงการดูเหมือนจะเป็นอย่างที่ผู้คนเข้ามาและด้วยวิธีนี้ทุกคนสามารถเปลี่ยนแปลงสิ่งเล็ก ๆ น้อย ๆ ได้โดยไม่ต้องขุดเข้าไปในโครงสร้างของแอปพลิเคชัน นอกจากนี้คุณสามารถเปลี่ยนชื่อของกลุ่มกล่อง / หน้าแท็บที่คล้ายกันได้อย่างง่ายดายในครั้งเดียว อีกแง่มุมหนึ่งคือคุณสามารถพิมพ์คลาสนั้นและมอบให้กับผู้ที่ไม่ใช่โปรแกรมเมอร์ซึ่งสามารถตรวจสอบคำอธิบายภาพว่าใช้งานง่ายหรือไม่และข้อความที่ส่งถึงผู้ใช้นั้นละเอียดเกินไปหรือสับสนเกินไป อย่างไรก็ตามฉันเห็นข้อเสียบางอย่าง: ทุกชั้นเรียนจะถูกผนวกเข้ากับชั้นเรียนอย่างต่อเนื่อง การเพิ่ม / ลบ / เปลี่ยนชื่อ / ย้ายค่าคงที่ต้องมีการคอมไพล์ใหม่อย่างน้อย 90% ของแอปพลิเคชัน …

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

1
ทำไมฐานข้อมูลเป็นคิวไม่ดี? [ปิด]
ฉันเพิ่งอ่านบทความนี้และฉันสับสน ลองจินตนาการ 1 webapp และ 1 แอพลิเคชันที่แตกต่างกันทำหน้าที่เป็น "คนงาน" ทั้งสองร่วมกันฐานข้อมูลเดียวกัน โอ้ฉันพูดว่า "การแบ่งปัน" .. แต่บทความจะเตือนอะไร : ประการที่สี่การแบ่งปันฐานข้อมูลระหว่างแอปพลิเคชัน (หรือบริการ) เป็นสิ่งที่ไม่ดี มันเป็นการล่อลวงเกินไปที่จะทำให้รัฐร่วมอสัณฐานอยู่ในนั้นและก่อนที่คุณจะรู้ว่าคุณจะมีสัตว์ประหลาดคู่ขนานอย่างมหาศาล => ไม่เห็นด้วย มีบางกรณีที่แอปพลิเคชันที่แตกต่างยังคงเป็นส่วนหนึ่งของหน่วยเดียวกันดังนั้นแนวคิดของ "ปัญหาการมีเพศสัมพันธ์" จึงไม่มีเหตุผลในกรณีนี้ มาดำเนินการต่อ: เว็บแอปจัดการคำขอ HTTP ของไคลเอ็นต์และอาจอัปเดตเมื่อใดก็ได้ที่มีการรวม (คำศัพท์ DDD) เพื่อสร้างกิจกรรมโดเมนที่สอดคล้องกัน เป้าหมายของผู้ปฏิบัติงานคือการจัดการกิจกรรมโดเมนเหล่านั้นโดยการประมวลผลงานที่ต้องการ ประเด็นก็คือ: ข้อมูลเหตุการณ์ควรส่งผ่านไปยังผู้ปฏิบัติงานอย่างไร วิธีแรกในการส่งเสริมการอ่านบทความคือการใช้ RabbitMQ เป็นมิดเดิลแวร์ที่มุ่งเน้นข้อความ เวิร์กโฟลว์จะง่าย: เมื่อใดก็ตามที่เว็บไดโนสร้างเหตุการณ์มันจะเผยแพร่ผ่าน RabbitMQ ซึ่งฟีดคนงาน ข้อเสียเปรียบก็คือไม่มีสิ่งใดรับประกันความสอดคล้องทันทีระหว่างการคอมมิชชันของการอัพเดตแบบรวมและการเผยแพร่เหตุการณ์โดยไม่ต้องจัดการกับความล้มเหลวในการส่งที่เป็นไปได้ ... หรือปัญหาฮาร์ดแวร์; นั่นเป็นอีกประเด็นหลัก ตัวอย่าง: เป็นไปได้ว่าเหตุการณ์ถูกเผยแพร่โดยไม่ประสบความสำเร็จในการอัปเดตรวม ... ส่งผลให้เกิดเหตุการณ์ที่แสดงถึงการแสดงโมเดลโดเมนที่ผิดพลาด คุณสามารถยืนยันได้ว่า XA …

8
SOLID, หลีกเลี่ยงโดเมนโลหิตจาง, การฉีดพึ่งพา?
แม้ว่านี่อาจเป็นคำถามที่ไม่เชื่อเรื่องภาษา แต่ฉันก็สนใจที่จะตอบคำถามเกี่ยวกับระบบนิเวศ. NET นี่คือสถานการณ์สมมติว่าเราจำเป็นต้องพัฒนาแอปพลิเคชั่นคอนโซลอย่างง่ายสำหรับการบริหารสาธารณะ แอปพลิเคชันเกี่ยวกับภาษีรถยนต์ พวกเขา (เท่านั้น) มีกฎเกณฑ์ทางธุรกิจดังต่อไปนี้: 1.a) หากยานพาหนะเป็นรถยนต์และครั้งสุดท้ายที่เจ้าของชำระภาษีคือ 30 วันที่ผ่านมาเจ้าของจะต้องจ่ายอีกครั้ง 1.b) หากยานพาหนะเป็นมอเตอร์ไซค์และครั้งสุดท้ายที่เจ้าของชำระภาษีคือ 60 วันที่ผ่านมาเจ้าของจะต้องจ่ายอีกครั้ง กล่าวอีกนัยหนึ่งถ้าคุณมีรถคุณต้องจ่ายทุก ๆ 30 วันหรือถ้าคุณมีมอเตอร์ไซค์คุณต้องจ่ายทุก ๆ 60 วัน สำหรับยานพาหนะแต่ละคันในระบบแอปพลิเคชันควรทดสอบกฎเหล่านั้นและพิมพ์ยานพาหนะเหล่านั้น (หมายเลขทะเบียนรถและข้อมูลเจ้าของรถ) ที่ไม่เป็นที่พอใจ สิ่งที่ฉันต้องการคือ: 2.a) สอดคล้องกับหลักการ SOLID (โดยเฉพาะอย่างยิ่งหลักการ Open / Closed) สิ่งที่ฉันไม่ต้องการคือ (ฉันคิดว่า): 2.b) โดเมนโลหิตจางดังนั้นตรรกะทางธุรกิจจึงควรเข้าสู่องค์กรธุรกิจ ฉันเริ่มต้นด้วยสิ่งนี้: public class Person // You wanted a banana but what you …
33 c#  .net  design  architecture 

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

2
วิธีการออกแบบระบบการแจ้งเตือนที่ปรับขนาดได้? [ปิด]
ฉันต้องเขียนผู้จัดการระบบการแจ้งเตือน นี่คือข้อกำหนดของฉัน: ฉันต้องสามารถส่งการแจ้งเตือนบนแพลตฟอร์มที่แตกต่างกันซึ่งอาจแตกต่างกันโดยสิ้นเชิง (สำหรับตัวอย่างฉันต้องสามารถส่ง SMS หรืออีเมลได้) บางครั้งการแจ้งเตือนอาจเหมือนกันสำหรับผู้รับทุกคนสำหรับแพลตฟอร์มที่กำหนด แต่บางครั้งอาจเป็นการแจ้งเตือนต่อผู้รับ (หรือหลายคน) ต่อแพลตฟอร์ม การแจ้งเตือนแต่ละครั้งสามารถมีส่วนของข้อมูลเฉพาะแพลตฟอร์มได้ (สำหรับตัวอย่าง MMS ที่มีเสียงหรือภาพ) ระบบจำเป็นต้องปรับขนาดได้ฉันต้องสามารถส่งการแจ้งเตือนจำนวนมากโดยไม่ต้องหยุดทำงานทั้งแอปพลิเคชันหรือเซิร์ฟเวอร์ มันเป็นกระบวนการสองขั้นตอนแรกที่ลูกค้าอาจพิมพ์ข้อความและเลือกแพลตฟอร์มที่จะส่งไปและควรสร้างการแจ้งเตือนเพื่อประมวลผลแบบเรียลไทม์ในภายหลัง จากนั้นระบบจะต้องส่งการแจ้งเตือนไปยังผู้ให้บริการแพลตฟอร์ม สำหรับตอนนี้ฉันจบลงด้วยบางอย่าง แต่ฉันไม่รู้ว่ามันจะปรับขนาดได้หรือถ้ามันเป็นการออกแบบที่ดี ฉันว่าวัตถุต่อไปนี้ (ในภาษาเทียม): Notificationวัตถุทั่วไป: class Notification { String $message; Payload $payload; Collection<Recipient> $recipients; } ปัญหาเกี่ยวกับวัตถุต่อไปนี้จะเกิดอะไรขึ้นถ้าฉันมีผู้รับ 1,000,000? แม้ว่าRecipientวัตถุนั้นจะเล็กมากมันก็จะใช้หน่วยความจำมากเกินไป ฉันสามารถสร้างการแจ้งเตือนได้หนึ่งรายการต่อผู้รับ แต่ผู้ให้บริการแพลตฟอร์มบางรายกำหนดให้ฉันส่งเป็นชุดซึ่งหมายความว่าฉันต้องกำหนดหนึ่งการแจ้งเตือนที่มีผู้รับหลายคน การแจ้งเตือนที่สร้างขึ้นแต่ละครั้งสามารถเก็บไว้ในที่เก็บข้อมูลถาวรเช่น DB หรือ Redis มันจะเป็นการดีหรือไม่ที่จะรวมกันในภายหลังเพื่อให้แน่ใจว่าสามารถปรับขนาดได้หรือไม่? ในขั้นตอนที่สองฉันต้องดำเนินการการแจ้งเตือนนี้ แต่ฉันจะแยกแยะการแจ้งเตือนกับผู้ให้บริการแพลตฟอร์มที่เหมาะสมได้อย่างไร ฉันควรใช้วัตถุเช่นMMSNotificationขยายabstract Notificationหรือไม่ หรือสิ่งที่ต้องการNotification.setType('MMS')? เพื่อให้สามารถประมวลผลการแจ้งเตือนจำนวนมากในเวลาเดียวกันฉันคิดว่าระบบคิวการส่งข้อความเช่น RabbitMQ อาจเป็นเครื่องมือที่เหมาะสม …

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

20
หนังสือที่ดีที่สุดเกี่ยวกับทฤษฎีและการปฏิบัติของสถาปัตยกรรมซอฟต์แวร์? [ปิด]
ฉันมีนักพัฒนาสองสามคนที่ บริษัท ของฉันซึ่งต้องการเปลี่ยนจากการเขียนโปรแกรมมาเป็นสถาปัตยกรรม หนังสือที่ดีที่สุดในทฤษฎีและการปฏิบัติของสถาปัตยกรรมซอฟต์แวร์คืออะไร? รวมภาพหน้าปกถ้าทำได้ รู้สึกฟรีที่จะรวมหนังสือทั่วไปและหนังสือที่เกี่ยวข้องกับเทคโนโลยีเฉพาะ

2
วิธีการแยกส่วนหน้าและส่วนหลังด้วยจาวาสคริปต์แบบเต็ม?
สมมติว่าฉันมีส่วนหน้าซึ่งส่วนใหญ่เป็นแอปพลิเคชันหน้าเดียวที่เขียนโดยใช้เชิงมุมเสียงฮึดฮัดและความโกลาหล และสมมติว่าฉันมีแบ็กเอนด์ซึ่งส่วนใหญ่เป็นเพียง REST API นั่งอยู่ด้านบนของ ORM ซึ่งเก็บ / ดึงวัตถุจากฐานข้อมูลโดยใช้สิ่งต่าง ๆ เช่นเสียงฮึดฮัดแสดงและต่อเนื่อง แอปพลิเคชันเชิงมุมทำสิ่งที่เป็นภาพทั้งหมดที่ผู้ใช้เห็น แต่ทำได้ด้วยการเป็น GUI เหนือบริการที่จัดทำโดยแบ็คเอนด์ มันจะเป็นที่พึงปรารถนาที่จะแยกสิ่งเหล่านี้ออกเป็นสอง codebases ที่แตกต่างกันเพื่อให้เกิดการพัฒนาที่เป็นอิสระการกำหนดเวอร์ชันการรวมอย่างต่อเนื่องการผลักดันการพัฒนาเป็นต้น คำถามของฉันคือมีวิธีการอะไรบ้างสำหรับการทำสิ่งนี้อย่างหมดจด? มีแนวทางปฏิบัติที่ดีที่สุดสำหรับจาวาสคริปต์แบบเต็มสแต็คหรือไม่? ตัวเลือก # 1 ดูเหมือนจะเป็นหินใหญ่ก้อนเดียวเช่น "อย่าแยกพวกมันออก" โปรคือห่วงโซ่การสร้างนั้นง่ายและทุกอย่างอยู่ในที่แห่งเดียว - แต่ดูเหมือนจะมีข้อเสียมากมาย เวอร์ชันที่ยากขึ้นไปอีกส่วนด้านหน้าที่หักหมายถึงส่วนที่ไม่สามารถปรับใช้ได้และอื่น ๆ ตัวเลือก # 2 ดูเหมือนจะเป็นแบบโมโนลิ ธ ที่ซึ่งฟลูเอ็นด์บิลด์ส่วนหน้ามีผลในการเขียนไฟล์จำนวนมากไปยังแบ็คเอนด์ distไดเรกทอรีบน front-end จะอ้างถึงไดเรกทอรีบางอย่างเกี่ยวกับ back-end เพื่อเป็นหลักเมื่อ minifies ปลายด้านหน้า uglifies ฯลฯ ก็ลงท้ายเผยแพร่ไปยัง back-end ซึ่งจะทำงานทุกอย่าง ตัวเลือก # …

6
มันจะโอเคที่จะมีกลิ่นรหัสหรือไม่ถ้ายอมรับวิธีแก้ปัญหาที่ง่ายกว่าสำหรับปัญหาอื่น? [ปิด]
กลุ่มเพื่อนและฉันทำงานในโครงการเมื่อไม่นานมานี้และเราต้องการคิดค้นวิธี OOP ที่ดีเพื่อแสดงสถานการณ์ที่เฉพาะเจาะจงกับผลิตภัณฑ์ของเรา โดยพื้นฐานแล้วเรากำลังทำงานกับเกมกระสุนนรกสไตล์ Touhou และเราต้องการสร้างระบบที่เราสามารถแสดงพฤติกรรมที่เป็นไปได้ของกระสุนได้อย่างง่ายดายที่เราสามารถฝันได้ นั่นคือสิ่งที่เราทำ เราสร้างสถาปัตยกรรมที่สง่างามอย่างแท้จริงซึ่งทำให้เราสามารถแยกพฤติกรรมของกระสุนปืนออกเป็นส่วนประกอบต่าง ๆ ที่สามารถแนบไปกับกระสุนได้ตามใจชอบระบบส่วนประกอบของ Unity มันใช้งานได้ดีมันขยายได้ง่ายมีความยืดหยุ่นและครอบคลุมฐานทั้งหมดของเรา แต่มีปัญหาเล็กน้อย แอปพลิเคชันของเรายังเกี่ยวข้องกับการสร้างขั้นตอนจำนวนมากกล่าวคือเราสร้างพฤติกรรมของกระสุน เหตุใดจึงเป็นปัญหา วิธีแก้ปัญหา OOP ของเราคือการแสดงพฤติกรรมกระสุนในขณะที่สง่างามมีความซับซ้อนเล็กน้อยในการทำงานโดยไม่มีมนุษย์ มนุษย์ฉลาดพอที่จะคิดถึงวิธีแก้ปัญหาที่มีเหตุผลและชาญฉลาด อัลกอริธึมการสร้างโพรซีเดอร์ยังไม่ฉลาดและเราพบว่ามันยากที่จะใช้ AI ที่ใช้สถาปัตยกรรม OOP ของเราให้มีศักยภาพสูงสุด เป็นที่ยอมรับว่าเป็นข้อบกพร่องของสถาปัตยกรรมคือมันไม่ง่ายในทุกสถานการณ์ ดังนั้นเพื่อแก้ไขปัญหานี้โดยทั่วไปเราได้ผลักดันพฤติกรรมทั้งหมดที่ส่วนประกอบต่าง ๆ นำเสนอให้กับคลาสกระสุนเพื่อให้ทุกสิ่งที่เราสามารถจินตนาการได้ถูกนำเสนอโดยตรงในแต่ละอินสแตนซ์ของสัญลักษณ์แสดงหัวข้อย่อย นี้จะทำให้ขั้นตอนรุ่นของเราขั้นตอนวิธีการง่ายขึ้นเล็ก ๆ น้อย ๆ ในการทำงานด้วย แต่ตอนนี้ระดับกระสุนของเราเป็นอย่างมากวัตถุพระเจ้า มันเป็นคลาสที่ใหญ่ที่สุดในโปรแกรมอย่างง่ายจนมีโค้ดมากกว่าห้าเท่ามากกว่าอย่างอื่น มันค่อนข้างเจ็บปวดที่ต้องดูแลเช่นกัน เป็นไรไหมที่ชั้นเรียนของเราคนหนึ่งเปลี่ยนเป็นเทพเจ้าวัตถุเพื่อให้ง่ายต่อการทำงานกับปัญหาอื่น? โดยทั่วไปแล้วจะเป็นการดีไหมที่จะมีกลิ่นของรหัสในรหัสของคุณหากยอมรับวิธีการแก้ปัญหาที่ง่ายกว่าสำหรับปัญหาอื่น

6
อะไรคือข้อโต้แย้งกับการใช้ EntityFramework? [ปิด]
แอปพลิเคชันที่ฉันกำลังสร้างกำลังใช้โพรซีเดอร์ Stored และโมเดลคลาสที่สร้างขึ้นด้วยมือเพื่อแสดงวัตถุฐานข้อมูล บางคนแนะนำให้ใช้ Entity Framework และฉันกำลังพิจารณาเปลี่ยนไปใช้เนื่องจากฉันไม่ได้อยู่ในโครงการ ปัญหาของฉันคือฉันรู้สึกว่าคนที่โต้เถียงกับ EF กำลังบอกฉันถึงสิ่งที่ดีไม่ใช่สิ่งไม่ดี :) ความกังวลหลักของฉันคือ: เราต้องการการตรวจสอบฝั่งไคลเอ็นต์โดยใช้ DataAnnotations และดูเหมือนว่าฉันจะต้องสร้างแบบจำลองฝั่งไคลเอ็นต์ต่อไปดังนั้นฉันไม่แน่ใจว่า EF จะประหยัดเวลาการเข้ารหัสมาก เราต้องการให้ชั้นเรียนมีขนาดเล็กที่สุดเท่าที่จะเป็นไปได้เมื่อผ่านเครือข่ายและฉันได้อ่านว่าการใช้ EF มักจะมีข้อมูลเพิ่มเติมที่ไม่จำเป็น เรามีเลเยอร์ฐานข้อมูลที่ซับซ้อนซึ่งข้ามหลายฐานข้อมูลและฉันไม่แน่ใจว่า EF สามารถจัดการสิ่งนี้ได้ เรามีฐานข้อมูลทั่วไปหนึ่งฐานที่มีสิ่งต่าง ๆ เช่นผู้ใช้ StatusCodes ประเภท ฯลฯ และหลายอินสแตนซ์ของฐานข้อมูลหลักของเราสำหรับอินสแตนซ์ต่าง ๆ ของแอปพลิเคชัน SELECT SELECT สามารถและจะสืบค้นข้ามทุกอินสแตนซ์ของฐานข้อมูลอย่างไรก็ตามผู้ใช้สามารถแก้ไขวัตถุที่อยู่ในฐานข้อมูลที่ทำงานอยู่ในปัจจุบันเท่านั้น พวกเขาสามารถสลับฐานข้อมูลโดยไม่ต้องโหลดแอปพลิเคชันซ้ำ โหมดวัตถุมีความซับซ้อนมากและมักจะมีการเข้าร่วมค่อนข้างน้อย ข้อโต้แย้งสำหรับ EF คือ: เห็นพ้องด้วย ฉันไม่ต้องใช้รหัสในการตรวจสอบเพื่อดูว่าบันทึกได้รับการปรับปรุงก่อนการบันทึกแต่ละครั้งหรือไม่ การสร้างรหัส EF สามารถสร้างโมเดลคลาสบางส่วนและ POCO ให้ฉันได้ แต่ฉันไม่แน่ใจว่าจะช่วยฉันได้มากเพราะฉันคิดว่าเรายังคงต้องสร้างโมเดลฝั่งไคลเอ็นต์สำหรับการตรวจสอบความถูกต้องและวิธีการแยกวิเคราะห์แบบกำหนดเอง ความเร็วในการพัฒนาเนื่องจากเราไม่จำเป็นต้องสร้างขั้นตอนการจัดเก็บ CRUD …

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

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