คุณจัดระเบียบโครงการอย่างไร [ปิด]

คุณมีรูปแบบเฉพาะของการจัดระเบียบโครงการหรือไม่?

ตัวอย่างเช่นขณะนี้ฉันกำลังสร้างโครงการสำหรับโรงเรียนสองแห่งที่นี่ในโบลิเวียนี่คือวิธีที่ฉันจัดระเบียบ:

TutoMentor (Solution)
TutoMentor.UI   (Winforms project)
TutoMentor.Data (Class library project)

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

ในส่วน UI ของแอปพลิเคชันของฉันฉันมีปัญหาในการตัดสินใจเลือก schema ที่ดีเพื่อจัดระเบียบแบบฟอร์มต่าง ๆ และที่ที่พวกเขาอยู่

แก้ไข:

สิ่งที่เกี่ยวกับการจัดระเบียบแบบฟอร์มต่าง ๆ ในโครงการ. UI ฉันควรจัดกลุ่มฟอร์มที่แตกต่างกันที่ไหน? การทำให้พวกเขาทั้งหมดอยู่ในระดับรากของโครงการเป็นความคิดที่ไม่ดี

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

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

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

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

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

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

SolutionName

.ProjectNameDocuments
    For large projects there are certain documents that need to be kept with
    it. For this I actually create a separate project or folder within the 
    solution to hold them.
.ProjectNameUnitTest
    Unit testing always depends on the project - sometimes it is just really 
    basic to catch edge cases and sometimes it is set up for full code 
    coverage.  I have recently added graphical unit testing to the arsenal.
.ProjectNameInstaller
    Some projects have specific installation requirements that need to be 
    handled at a project level.
.ProjectNameClassLibrary
    If there is a need for web services, APIs, DLLs or such.
.ProjectNameScripts (**Added 2/29/2012**)
    I am adding this because I just found a need for one in my current project.  
    This project holds the following types of scripts: SQL (Tables, procs, 
    views), SQL Data update scripts, VBScripts, etc.
.ProjectName
    .DataRepository 
        Contains base data classes and database communication.  Sometimes 
        also hold a directory that contains any SQL procs or other specific 
        code.  
    .DataClasses
        Contains the base classes, structs, and enums that are used in the 
        project.  These may be related to but not necessarily be connected
        to the ones in the data repository.
    .Services 
        Performs all CRUD actions with the Data, done in a way that the 
        repository can be changed out with no need to rewrite any higher 
        level code.
    .Business
        Performs any data calculations or business level data validation,
        does most interaction with the Service layer.
    .Helpers
        I always create a code module that contains helper classes.  These 
        may be extensions on system items, standard validation tools, 
        regular expressions or custom-built items.  
    .UserInterface
        The user interface is built to display and manipulate the data.  
        UI Forms always get organized by functional unit namespace with 
        additional folders for shared forms and custom controls.

ฉันชอบแบ่งโครงการเป็นเลเยอร์

ด้วยวิธีนี้ง่ายต่อการจัดการการพึ่งพาแบบวนรอบ ฉันรับประกันได้ว่าไม่มีโครงการใดที่กำลังนำเข้ามุมมองโครงการ (เลเยอร์) โดยไม่ได้ตั้งใจ ฉันยังมีแนวโน้มที่จะทำลายชั้นของฉันในชั้นย่อย ดังนั้นโซลูชันทั้งหมดของฉันจึงมีรายการโครงการเช่นนี้:

• Product.Core
• Product.Model
• Product.Presenter
• Product.Persistence
• Product.UI
• Product.Validation
• Product.Report
• Product.Web

พวกเขาเป็น "บล็อกอาคาร" ที่ใหญ่กว่าของแอปพลิเคชันของฉัน จากนั้นภายในแต่ละโปรเจคฉันจัดระเบียบในเนมสเปซมากขึ้นอย่างมีเหตุผล แต่ก็แตกต่างกันมาก สำหรับ UI เมื่อสร้างแบบฟอร์มจำนวนมากฉันพยายามคิดในส่วนของอวกาศแล้วสร้างเนมสเปซสำหรับ "ช่องว่าง" แต่ละอัน สมมติว่ามีกลุ่มผู้ใช้กำหนดรูปแบบการควบคุมและรูปแบบของผู้ใช้ฉันมีเนมสเปซที่เรียกว่า UserPreferences สำหรับพวกเขาและอื่น ๆ

การจัดโครงการ

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

ตัวอย่างเช่นบางครั้งเพียงแค่มีโครงการนี้ซึ่งมีเฟรมเวิร์กทั้งชุด (อีเมลการบันทึกและอื่น ๆ ) ก็เพียงพอแล้ว:

MyCompany.Frameworks

ในบางครั้งฉันอาจต้องการแยกเฟรมเวิร์กออกเป็นชิ้น ๆ เพื่อให้สามารถนำเข้าทีละรายการ:

MyCompany.Frameworks.Networking
MyCompany.Frameworks.Logging
MyCompany.Frameworks.SomeLOBFramework

การจัดระเบียบแบบฟอร์ม

การจัดระเบียบแบบฟอร์มภายใต้โครงการ UI จะแปรเปลี่ยนอย่างแท้จริงเมื่อโครงการของคุณขยาย

• ขนาดเล็ก - โฟลเดอร์แบบฟอร์มอย่างง่ายอาจเพียงพอสำหรับโครงการขนาดเล็กมาก บางครั้งคุณสามารถ overengineer โครงสร้างเหมือนคุณสามารถ namespaces และทำให้สิ่งต่าง ๆ มีความซับซ้อนเกินกว่าที่พวกเขาจะต้อง

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

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

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

สำหรับคำแนะนำเกี่ยวกับสถาปัตยกรรมของระบบโปรดดูไซต์รูปแบบและการปฏิบัติของ Microsoft

เมื่อฉันเขียนโค้ดใน. NET มีแนวโน้มชัดเจนที่จะมีกลุ่มของฟังก์ชั่นที่เกี่ยวข้อง ซึ่งแต่ละชุดอาจมีชุดย่อยเหมือนกัน ฉันชอบที่จะแยกกลุ่มหลักทางกายภาพ - หนึ่งในโครงการ VS เหล่านี้ จากนั้นฉันก็แบ่งย่อยอย่างมีเหตุผลโดยใช้ชุดประกอบ ตามรูปแบบนี้หนึ่งในโครงการปัจจุบันของฉันมีลักษณะเช่นนี้:

• Wadmt (โซลูชัน)
  • Wadmt.Common
  • Wadmt.Data
    • Wadmt.Data.MySql
    • Wadmt.Data.SqlServer
    • Wadmt.Data.Oracle
  • Wadmt.Domain
  • Wadmt.Services
  • Wadmt.Tests
    • Wadmt.Tests.Common
    • Wadmt.Tests.Domain
    • Wadmt.Tests.Services
    • Wadmt.Tests.Integration
  • Wadmt.Web

หวังว่าจะเป็นประโยชน์กับคุณ ระดับการแยกต้องใช้เวลาพอสมควรในการคิด

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

Company (solution)
  Company.Common (shared library)
  Company.Project (Main application UI)
  Company.Project.UnitTests (Unit tests for all project modules)
  Company.Project.IntegrationTests (integration tests for all project modules)
  Company.Project.AutomationTests (tests that invoke the UI)

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

  Company.Project.Model (ORM and business logic layer)
  Company.Project.Webapp (Web frontend/web service layer)
  Company.Project.WebClient (client code for web services)

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

เป็นเรื่องที่น่าสนใจที่ผู้คนจำนวนมากไม่พิจารณา DRY ที่นี่ มันเกิดขึ้นสองสามครั้งในชีวิตของฉันที่นักพัฒนาสร้างโครงสร้างไดเรกทอรีที่ไม่สามารถสร้างได้เพราะสิ่งนั้น กันไม่ให้ชื่อโครงการออกจากโซลูชันและไดเรกทอรีโครงการ!

ดังนั้นนี่คือวิธีของฉัน:

{drive}:\{customer}\{apps|libs|tools}\{project}
  - cer
  - res
  - src
   - Common
   - Data
   - UI
   - Logic
   - Logic._Tests  

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

โมดูลเหล่านั้นเป็นโครงการภายใต้โซลูชันของฉัน(โดยปกติคือไลบรารีคลาส ) แต่ละโมดูลมีเนมสเปซที่แตกต่างและการออกแบบของตัวเอง (ที่มีคลาสฯลฯ )

หนึ่งในโมดูลเหล่านั้นคือGUI ( ส่วนต่อประสานกราฟิกผู้ใช้ )

ฉันมักจะใช้เครื่องมือควบคุมการแก้ไขเพื่อติดตามการเปลี่ยนแปลงในแต่ละโครงการ ผมขอแนะนำให้Git มันเป็น opensource แจกจ่ายและใช้งานฟรี

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

ตัวอย่างสองตัวอย่าง:

1. หากโครงการอ้างถึงการสร้างหน้าจอข้อมูลอินพุตเท่านั้น ส่วนใหญ่ฉันจะใช้รูปแบบ MVC
2. หากโครงการกำลังจะถูกใช้เป็น UI หนักซึ่งส่วนใหญ่สนับสนุนแพลตฟอร์มทวีคูณรูปแบบ MVVM desgin จะเป็นประโยชน์

โปรดจำไว้ว่าสิ่งเหล่านี้จะบังคับให้คุณจัดระเบียบโครงการของคุณในแบบเฉพาะ

นี่คือการอ่านสำหรับคุณ:

รูปแบบการออกแบบสุทธิ

รูปแบบการออกแบบ

การออกแบบเชิงวัตถุ

หวังว่านี่จะช่วยได้