แนวปฏิบัติที่ดีเกี่ยวกับ Visual Studio Solutions [ปิด]

หวังว่าคำถามง่ายๆสัมพัทธภาพ ฉันเริ่มทำงานในโครงการภายในใหม่เพื่อสร้างความสามารถในการรองรับอุปกรณ์ที่ได้รับการซ่อมแซมภายในอาคารได้

ฐานข้อมูลจะถูกจัดเก็บจากระยะไกลบนเว็บเซิร์ฟเวอร์และจะสามารถเข้าถึงได้ผ่านทางเว็บ API (JSON เอาต์พุต) และได้รับการปกป้องด้วย OAuth GUI ปลายด้านหน้ากำลังดำเนินการใน WPF และรหัสธุรกิจใน C #

จากนี้ฉันเห็นเลเยอร์ที่แตกต่างกันการนำเสนอ / แอพลิเคชัน / Datastore จะมีรหัสสำหรับจัดการการโทรที่ผ่านการรับรองความถูกต้องทั้งหมดไปยัง API, คลาสเพื่อเป็นตัวแทน (วัตถุธุรกิจ), คลาสเพื่อสร้างเอนทิตี (วัตถุธุรกิจ), ชิ้นส่วนสำหรับ WPF GUI, ชิ้นส่วนของ WPF viewmodels เป็นต้น

เป็นการดีที่สุดที่จะสร้างสิ่งนี้ในโครงการเดียวหรือแยกพวกมันออกเป็นแต่ละโครงการ?

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

ขึ้นอยู่กับขนาดของโครงการ

นี่คือแนวทางที่ฉันมักจะใช้

• โครงการขนาดเล็กที่มีหน้าไม่กี่หน้าหรือน้อยกว่าฉันมักจะทำโครงการเดียวเสมอ

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

• หากโครงการมีขนาดใหญ่กว่าฉันจะมีโครงการแยกต่างหากสำหรับ DAL และการแยกเพิ่มเติมขึ้นอยู่กับขอบเขตของการทำงานของแอปพลิเคชัน

• หากแอปพลิเคชั่นมีจุดประสงค์หลายอย่างแต่ละรายการมีมุมมองเป็นของตัวเอง, มุมมองแบบอื่น ๆ , โดยทั่วไปฉันจะแยกแต่ละส่วนออกเป็นพื้นที่ของตัวเอง หากแต่ละส่วนมีขนาดเล็กฉันแยกพวกมันออกเป็นโฟลเดอร์ หากแต่ละส่วนมีขนาดใหญ่ฉันจะแยกพวกเขาออกจากโครงการ

• ถ้าผมมีหลายโครงการที่ต้องอ้างอิงชุดเดียวกันของวัตถุ ( ViewModelBase, RelayCommandฯลฯ ) ฉันจะสร้างโครงการเพียงสำหรับวัตถุโครงสร้างพื้นฐานที่ใช้ร่วมกัน

• หากฉันมีสไตล์ / เทมเพลต / ทรัพยากรที่กำหนดเองที่แชร์กันเป็นจำนวนมากฉันจะสร้างโครงการสำหรับเหล่านั้นโดยเฉพาะ

ในฐานะที่เป็นบันทึกด้านข้างฉันทำผิดพลาดกับโครงการ WPF ขนาดใหญ่ครั้งแรกของฉันและแยกพวกเขาโดยการวางนางแบบในโครงการหนึ่ง, ดูในอีกโครงการและ ViewModels ในหนึ่งในสาม ฉันสามารถบอกคุณได้ว่าตอนนี้ไม่ใช่วิธีที่จะไปเนื่องจากการบำรุงรักษากลายเป็นฝันร้าย :)

ฉันเห็นผลลัพธ์ที่ดีที่สุดด้วยหนึ่งโครงการต่อชั้นรวมทั้งโครงการทดสอบต่อชั้น ฉันได้เห็นการใช้งานไม่กี่คนที่ไม่สามารถทำได้ใน 10 หรือน้อยกว่าโครงการในการแก้ปัญหาที่แก้ปัญหาที่ครอบคลุมทุกอย่าง

อย่าตกหลุมพรางในการใช้โปรเจคที่คุณต้องการกำหนดเนมสเปซ ตันของโครงการไม่เพิ่มอะไรนอกจากค่าใช้จ่ายเพื่อผลประโยชน์

แยก IMHO นั้นดีกว่าเกือบทุกครั้ง ฉันมักจะแยกชั้นข้อมูลออกนอกเสียจากว่าโครงการนั้นจะมีความสำคัญ 100% เหตุผลก็คือเพราะชั้นข้อมูลมักจะถูกส่งผ่านบ่อยที่สุด คุณจะเชื่อมโยง GUI กับชั้นข้อมูลหลาย ๆ ครั้งและคาดว่ามันจะทำงานได้ดี สถานการณ์ทั่วไปที่พบได้บ่อยคือคุณมีชั้นข้อมูลเดียวและคุณต้องการให้กระจายออกไปในหลาย ๆ GUI (ASP.Net, WPF และแอป Silverlight เป็นต้น) มันยอดเยี่ยมเมื่อคุณสามารถสร้างโครงการเลเยอร์ข้อมูลและวาง dll นั้นไว้เป็นข้อมูลอ้างอิงใน GUI ถัดไปที่คุณสร้าง

สำหรับฉัน 4 * เป็นหมายเลขเวทย์มนตร์ โครงการหนึ่งสำหรับแต่ละชั้นและโครงการหนึ่งซึ่งกำหนดอินเทอร์เฟซ / DTO ทั้งหมดที่จำเป็นในการสื่อสารระหว่างพวกเขา

* 7 ถ้าคุณนับการทดสอบหน่วย

ฉันมักจะใช้วิธีแก้ปัญหาเดียวถ้าฉันทำงานในเลเยอร์ที่แตกต่างกันเหล่านั้นหรือถ้ามีการแต่งงานกันอย่างแน่นหนากับพวกเขา ฉันต้องการกด F5 และให้โครงการทั้งหมดสร้างใหม่หากจำเป็น ฉันไม่คิดว่าจะมีวิธี "ถูก" ที่จะทำ

รสนิยมส่วนตัวของมันเป็นสิ่งที่สำคัญที่สุดคือเพื่อให้สอดคล้อง ฉันมีโครงการแยกเป็นส่วนตัวสำหรับแต่ละชั้นของแอปพลิเคชันดังนั้นการแยกจึงชัดเจน

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

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

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

Visual Studio บางรุ่นพบปัญหาประสิทธิภาพการทำงานที่แอสเซมบลีประมาณ 15 บางครั้งก็ขึ้นอยู่กับชนิดของโครงการ บางครั้งการยกเลิกการโหลดไฟล์โครงการสามารถช่วยได้

เหตุผลที่ดีเพียงข้อเดียวที่มีมากกว่าหนึ่งโครงการคือถ้าคุณต้องการแชร์ชุดของคลาสและไฟล์ในหลาย ๆ แอปพลิเคชัน

หากมีการใช้งานโปรเจ็กต์เพียงแอปพลิเคชั่นเดียวก็ไม่ควรสร้างขึ้นมาตั้งแต่แรก ใช้เนมสเปซแทน ช่วยตัวเองให้พ้นปัญหาของการอ้างอิงแบบวงกลมค่าใช้จ่ายของ dll และความสับสนของโครงการเมื่อค้นหาไฟล์

อ่านบทความนี้เพื่ออธิบายคำอธิบายเชิงลึกว่าทำไมจึงเป็นเช่นนั้น: http://lostechies.com/chadmyers/2008/07/16/project-anti-pattern-many-projects-in-a-visual-studio- วิธีการแก้ปัญหาของไฟล์ /

และตามที่ระบุในบทความฉันยินดีต้อนรับทุกคนที่มีเหตุผลที่ถูกต้องที่จะมีหลายโครงการนอกเหนือจากการแบ่งปันรหัสผ่านแอปพลิเคชันเพื่อบอกฉันว่ามันคืออะไรเพราะฉันสงสัยว่ามีอะไรบ้าง