โครงสร้างไดเร็กทอรีสำหรับ. NET Solution

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

[Company.System.Feature]
  |-doc
     |Sandcastle project
  |-lib
     |Nuget packages
  |-src
    |-Project1 e.g. web
    |-Project2 e.g. business logic
    |-UnittestProject1
    |-Specs

โฟลเดอร์ doc มีโซลูชัน Sandcastle ตามที่อธิบายไว้ที่นี่: https://www.codeproject.com/Articles/15176/Sandcastle-Help-File-Builder (ดูที่: เส้นทางสัมบูรณ์และเส้นทางสัมพัทธ์) ดังนั้นโฟลเดอร์ doc มีโฟลเดอร์ช่วยเหลือซึ่งมีไฟล์ช่วยเหลือที่สร้างขึ้น โฟลเดอร์ lib มีแพ็คเกจ Nuget ทั้งหมด

มีแนวทางของ Microsoft ใดบ้างที่แนะนำวิธีจัดโครงสร้างของโซลูชัน ฉันเคยดูที่นี่: /programming/789389/project-structure-for-c-sharp-development-effort/789554?noredirect=1#comment86756309_789554 ที่อื่น ๆ บทความและคำถามส่วนใหญ่ที่ฉันอ่านดูเหมือนจะสร้างขึ้นระหว่างปี 2550-2552 ฉันเชื่อว่า Nuget เปิดตัวในปี 2010 มีแนวทางของ Microsoft บ้างไหม? ฉันอ่านเกี่ยวกับสิ่งที่เรียกว่าต้นไม้ศัลยแพทย์อย่างไรก็ตามเรื่องนี้ดูเหมือนจะไม่อยู่อีกต่อไป: https://archive.codeplex.com/?p=treesurgeon

ฉันกำลังใช้ TFS Cruise Control และ DDD นั้นสร้างความแตกต่าง

c# visual-studio

— w0051977
แหล่งที่มา

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

— Robert Harvey

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

— Robert Harvey

สิ่งที่แปลกก็คือการใส่แพคเกจ nuget ใน lib แทนแพ็คเกจ

— Ewan

@Ewan แพ็คเกจ nuget ไม่ได้อยู่ในpackagesนั้นอีกต่อไปสำหรับโครงการ dotnetcore และ VS2017 ตอนนี้พวกเขาอาศัยอยู่ในobjไดเรกทอรีของโครงการ

— David Arno

PFF! อัพเกรด?!?!? ดูเหมือนว่ามันจะทำให้ข้าวของแตกสลาย

— Ewan

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

มีความพยายามที่จะกำหนดโครงสร้างร่วมกันแก้ปัญหาผ่านทางเป็นโครงการนั่งร้าน นี่คือการมุ่งเน้นไปที่ F # มากกว่าแทนที่จะเป็น C # มันไม่ได้ถอดออกจริง ๆ และมีสัญญาณของการพัฒนาความคิดเล็ก ๆ น้อย ๆ ในทุกวันนี้

ชุดแนวทางที่ใช้งานและเป็นปัจจุบันที่สุดคือ David Fowler ซึ่งเป็นผู้พัฒนาของ Microsoft ในทีม ASP.NET แนวทางเหล่านี้มีการใช้โดยหลายแห่งใน Microsoft รวมถึงทีมงาน Roslyn (C # และ VB.Net compiler) คุณสามารถทำสิ่งที่แย่กว่านั้นได้

— เดวิดอาร์โน
แหล่งที่มา

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

— w0051977

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

— Robert Harvey

คุณจะใส่สเป็คหรือไม่? ในโฟลเดอร์การทดสอบหรือในไดเรกทอรีชื่อ Specs (ในไดเรกทอรีเดียวกันกับโฟลเดอร์ src)? ฉันเดาว่ามันไม่สำคัญมากเกินไป

— w0051977

@RobertHarvey: ยุติธรรมเพียงพอ แต่การอ้างถึงหน้านั้นเพียงอย่างเดียวโดยไม่มีการสำรองข้อมูลอีกต่อไปก็ไม่ใช่เหตุผลที่จะเปลี่ยนโครงสร้างโฟลเดอร์โครงการหากมีการสร้างที่แตกต่างออกไป

— Flater

คุณสามารถดูหลักเกณฑ์เดวิด Fowlers ในทางปฏิบัติที่มากที่สุดของโครงการมาเปิดที่ GitHub เช่นEnity กรอบ

— pfx