Làm thế nào để bạn tổ chức các dự án của bạn? [đóng cửa]

Bạn có bất kỳ phong cách đặc biệt của tổ chức dự án?

Ví dụ: hiện tại tôi đang tạo một dự án cho một vài trường học ở đây tại Bolivia, đây là cách tôi tổ chức nó:

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

Làm thế nào chính xác để bạn tổ chức dự án của bạn? Bạn có một ví dụ về một cái gì đó bạn tổ chức và tự hào? Bạn có thể chia sẻ ảnh chụp màn hình của khung Giải pháp không?

Trong khu vực UI của ứng dụng của tôi, tôi gặp khó khăn khi quyết định một lược đồ tốt để sắp xếp các biểu mẫu khác nhau và vị trí của chúng.

Biên tập:

Còn việc tổ chức các hình thức khác nhau trong dự án .UI thì sao? Ở đâu / làm thế nào tôi nên nhóm khác nhau? Đặt tất cả chúng ở cấp độ gốc của dự án là một ý tưởng tồi.

Khi thiết kế một dự án và bố trí kiến ​​trúc tôi bắt đầu từ hai hướng. Đầu tiên tôi nhìn vào dự án đang được thiết kế và xác định những vấn đề cần phải giải quyết. Tôi nhìn vào những người sẽ sử dụng nó và bắt đầu với một thiết kế UI thô. Tại thời điểm này tôi đang bỏ qua dữ liệu và chỉ nhìn vào những gì người dùng đang yêu cầu và ai sẽ sử dụng nó.

Khi tôi đã hiểu cơ bản về những gì họ đang yêu cầu, tôi xác định dữ liệu cốt lõi là gì họ sẽ thao tác và bắt đầu bố trí cơ sở dữ liệu cơ bản cho dữ liệu đó. Sau đó, tôi bắt đầu đặt câu hỏi để xác định các quy tắc kinh doanh bao quanh dữ liệu.

Bằng cách bắt đầu từ cả hai đầu một cách độc lập, tôi có thể đặt ra một dự án theo cách kết hợp hai đầu lại với nhau. Tôi luôn cố gắng giữ các thiết kế tách biệt càng lâu càng tốt trước khi ghép chúng lại với nhau, nhưng hãy ghi nhớ các yêu cầu của từng thiết kế khi tôi tiến về phía trước.

Khi tôi đã hiểu rõ về từng kết thúc của vấn đề, tôi bắt đầu đưa ra cấu trúc của dự án sẽ được tạo ra để giải quyết vấn đề.

Khi bố cục cơ bản của giải pháp dự án được tạo, tôi xem xét chức năng của dự án và thiết lập một bộ không gian tên cơ sở được sử dụng tùy thuộc vào loại công việc đang được thực hiện. Đây có thể là những thứ như Tài khoản, Giỏ hàng, Khảo sát, v.v.

Đây là cách bố trí giải pháp cơ bản mà tôi luôn bắt đầu. Khi các dự án được xác định rõ hơn, tôi tinh chỉnh nó để đáp ứng nhu cầu cụ thể của từng dự án. Một số khu vực có thể được hợp nhất với những khu vực khác và tôi có thể thêm một vài khu vực đặc biệt khi cần thiết.

Tên giải pháp

.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.

Tôi thích chia các dự án của tôi thành các lớp

Bằng cách đó, việc quản lý các phụ thuộc theo chu kỳ sẽ dễ dàng hơn. Tôi có thể đảm bảo rằng không có dự án nào đang nhập sai dự án (lớp). Tôi cũng có xu hướng phá vỡ các lớp của tôi trong các lớp phụ. Vì vậy, tất cả các giải pháp của tôi có một danh sách các dự án như thế này:

• Sản phẩm
• Dòng sản phẩm
• Sản phẩm.Presenter
• Sản phẩm.
• Sản phẩm.UI
• Sản phẩm. Xác nhận
• Sản phẩm. Dịch chuyển
• Sản phẩm.Web

Chúng là những "khối xây dựng" lớn hơn trong ứng dụng của tôi. Sau đó, bên trong mỗi dự án tôi tổ chức trong không gian tên hợp lý hơn nhưng nó thay đổi rất nhiều. Đối với giao diện người dùng khi tạo nhiều biểu mẫu, tôi cố gắng suy nghĩ theo cách phân chia không gian và sau đó tạo không gian tên cho mỗi "khoảng trắng". Giả sử có một loạt các điều khiển và biểu mẫu tùy chọn người dùng, tôi có một không gian tên gọi là UserPreferences cho họ, v.v.

Tổ chức dự án

Tôi thường cố gắng phân chia các dự án của mình theo không gian tên, như bạn nói. Mỗi tầng của một ứng dụng, hoặc thành phần là dự án riêng của nó. Khi nói đến cách tôi quyết định cách chia giải pháp của mình thành các dự án, tôi tập trung vào khả năng sử dụng lại và phụ thuộc của các dự án đó. Tôi nghĩ về việc các thành viên khác trong nhóm của tôi sẽ sử dụng dự án như thế nào và nếu các dự án khác mà chúng tôi tạo ra có thể có lợi từ việc sử dụng một số thành phần của hệ thống.

Ví dụ, đôi khi, chỉ cần có dự án này, có toàn bộ bộ khung (email, ghi nhật ký, v.v.) là đủ:

MyCompany.Frameworks

Những lần khác, tôi có thể muốn chia các khung thành nhiều phần để chúng có thể được nhập riêng lẻ:

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

Hình thức tổ chức

Tổ chức các biểu mẫu trong một dự án UI sẽ thực sự biến đổi khi dự án của bạn mở rộng.

• Nhỏ - Một thư mục Biểu mẫu đơn giản có thể đủ cho một dự án rất nhỏ. Đôi khi bạn có thể overengineer cấu trúc giống như bạn có thể đặt tên cho không gian và làm cho mọi thứ trở nên phức tạp hơn mức cần thiết.

• Trung bình đến lớn - Ở đây, tôi thường bắt đầu chia các biểu mẫu của mình thành các khu vực chức năng. Nếu tôi có một phần trong ứng dụng của mình có 3 biểu mẫu để quản lý người dùng và một số theo dõi các trận đấu và tỷ số bóng đá, thì tôi sẽ có một Biểu mẫu> Khu vực người dùng và Khu vực Biểu mẫu> Trò chơi hoặc những thứ tương tự. Nó thực sự phụ thuộc vào phần còn lại của dự án, tôi có bao nhiêu hình thức như thế nào để tôi phá vỡ nó.

Hãy nhớ rằng, vào cuối ngày không gian tên và thư mục sẽ ở đó để giúp bạn sắp xếp và tìm thấy mọi thứ nhanh hơn.

Thực sự, nó phụ thuộc vào nhóm của bạn, dự án của bạn và những gì dễ dàng hơn cho bạn. Tôi sẽ đề nghị rằng nói chung, bạn tạo các dự án riêng cho từng lớp / thành phần trong hệ thống của bạn, nhưng luôn có ngoại lệ.

Để được hướng dẫn về kiến ​​trúc hệ thống, hãy xem trang web về Thực tiễn và Mô hình của Microsoft.

Khi tôi viết mã bằng .NET, có một xu hướng rõ ràng là có các cụm chức năng liên quan. Mỗi trong số đó có thể có một số bộ phụ giống nhau. Tôi muốn phá vỡ các nhóm chính về mặt vật lý - một trong số đó cho mỗi dự án VS. Sau đó tôi tiếp tục chia nhỏ một cách hợp lý bằng cách sử dụng các cụm. Theo mô hình này, một trong những dự án hiện tại của tôi trông như thế này:

• Wadmt (giải pháp)
  • Wadmt.Common
  • Wadmt.Data
    • Wadmt.Data.MySql
    • Wadmt.Data.SqlServer
    • Wadmt.Data.Oracle
  • Wadmt.Domain
  • Wadmt.Service
  • Wadmt.Tests
    • Wadmt.Tests.Common
    • Wadmt.Tests.Domain
    • Wadmt.Tests. Dịch vụ
    • Wadmt.Tests.Integration
  • Wadmt.Web

Hy vọng rằng nó hữu ích cho bạn. Các mức độ tách biệt tôi đã mất một thời gian để tìm ra.

Thật tốt khi có một kế hoạch tổ chức các giải pháp của bạn, và có một số cách để thực hiện nó. Chúng tôi có một số chức năng được chia sẻ trên nhiều dự án, cũng cung cấp tính nhất quán cho người dùng của chúng tôi. Tổ chức dự án không phụ thuộc vào những gì chúng ta đang làm. Tại cốt lõi của nó, chúng tôi sẽ có:

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)

Từ đó nó thực sự phụ thuộc vào thiết lập. Nếu chúng ta có cả ứng dụng khách và giao diện web (hữu ích để thu thập kết quả sử dụng trong lớp học hoặc nghiên cứu khác), chúng ta cần một dự án có mã được chia sẻ chung (tức là các đối tượng dữ liệu sẽ được tuần tự hóa).

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

Các tiểu dự án khác có thể được thêm vào khi cần thiết. Như tôi đã nói, nó thực sự phụ thuộc vào dự án. Một số dự án thực sự đơn giản, và chỉ cần các yếu tố cốt lõi. Chúng tôi cố gắng chống lại sự phân tách dự án tùy ý, do đó, phân chia theo các lớp thực sự có ý nghĩa. Các lớp được xác định bởi những gì cần được chia sẻ trên các dự án, giải pháp hoặc những gì cần phải là plugin / tiện ích mở rộng.

Điều thú vị là rất nhiều người không xem xét DRY ở đây. Nó đã xảy ra một vài lần trong đời tôi rằng các nhà phát triển đã tạo ra các cấu trúc thư mục không thể xây dựng vì điều đó. Giữ tên dự án ra khỏi giải pháp và thư mục dự án!

Vì vậy, đây là cách của tôi:

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

Khi tôi thiết kế ứng dụng của mình, tôi luôn xem nó là các mô-đun với một số phụ thuộc giữa chúng. Khi tôi có một thiết kế trong đầu, sau đó tôi sử dụng chiến lược từ dưới lên để phát triển nó. Tôi phát triển từng mô-đun và sau đó tôi làm cho chúng hoạt động cùng nhau.

Vâng, các mô-đun đó là các dự án theo giải pháp của tôi (thường là các thư viện lớp ). Mỗi mô-đun có một không gian tên khác nhau và thiết kế riêng (chứa các lớp , v.v.).

Một trong những mô-đun đó là GUI ( Giao diện người dùng đồ họa ).

Tôi cũng luôn sử dụng công cụ Kiểm soát sửa đổi để theo dõi các thay đổi trong từng dự án. Tôi đề nghị Git . Đó là mã nguồn mở, phân phối và miễn phí sử dụng.

Mỗi lần tôi bắt đầu vào một dự án mới, tôi nhận được một thông số kỹ thuật rộng rãi về những gì nó phải làm. Có đầu vào này giúp tôi bằng cách cung cấp cho tôi một bối cảnh, do đó tôi đi trước và nghĩ phương pháp tốt nhất (hoặc phù hợp nhất) để đạt được các mục tiêu của dự án. Tại thời điểm này, tôi bắt đầu suy nghĩ trong đó các mô hình ký quỹ có thể giúp tôi cung cấp giải pháp dự định. Đây là nơi tôi bắt đầu tổ chức dự án, có tính đến các mẫu thiết kế tôi sẽ áp dụng cho dự án.

Một vài ví dụ:

1. Nếu dự án chỉ giới thiệu để xây dựng màn hình dữ liệu đầu vào. Hầu hết có lẽ tôi sẽ sử dụng một mô hình MVC.
2. Nếu dự án sẽ được sử dụng như một giao diện người dùng hạng nặng hỗ trợ nhiều nền tảng nhất, một mô hình giải mã MVVM sẽ trở nên hữu ích.

Hãy nhớ rằng mỗi điều này sẽ buộc bạn phải tổ chức dự án của bạn theo một cách cụ thể.

Đây là một số đọc cho bạn:

.Net Thiết kế mẫu .

Mẫu thiết kế .

Thiết kế hướng đối tượng .

Hi vọng điêu nay co ich.