Làm cách nào để cấu trúc nhiều giải pháp / dự án chồng chéo trong .Net?


16

Gần đây tôi đã bắt đầu làm việc cho một khách hàng mới với một cơ sở mã cũ, trong đó có nhiều giải pháp .net, mỗi giải pháp thường lưu trữ một số dự án duy nhất cho giải pháp đó nhưng sau đó "mượn" / "liên kết trong" (thêm dự án hiện tại) một số dự án khác về mặt kỹ thuật thuộc về các giải pháp khác (ít nhất là nếu bạn đi theo cấu trúc thư mục trong TFS)

Tôi chưa bao giờ thấy một thiết lập này đan xen, không có thứ tự xây dựng rõ ràng, đôi khi một dự án trong giải pháp A chỉ tham chiếu dlls trực tiếp từ thư mục đầu ra của dự án được lưu trữ trong giải pháp B, đôi khi dự án chỉ được đưa vào trực tiếp ngay cả khi nó nằm trong đó FAR đi trong cấu trúc thư mục.

Có vẻ như mọi thứ đã được tối ưu hóa cho sự lười biếng của nhà phát triển.

Khi tôi đối mặt với họ tại sao họ không có máy chủ CI, họ trả lời rằng thật khó để thiết lập mã được tổ chức như vậy. (Tôi đang thiết lập nó bây giờ và nguyền rủa tổ chức mã này)

Các giải pháp được tổ chức xung quanh các tạo phẩm triển khai (những thứ cần được triển khai cùng nằm trong cùng một giải pháp) mà tôi nghĩ là một quyết định sáng suốt, nhưng nội dung của các giải pháp đó (các dự án) ở khắp mọi nơi.

Có sự đồng thuận về một cách thực hành tốt nhất để sử dụng khi sử dụng lại các thư viện lớp chung trên nhiều giải pháp / tạo phẩm triển khai không,

  • Cách cấu trúc mã trong VCS
  • Làm cách nào để tạo điều kiện chia sẻ logic nghiệp vụ giữa các tạo phẩm triển khai riêng biệt

Câu trả lời:


9

Tôi chưa bao giờ là một người hâm mộ bao gồm các dự án hiện có thuộc về các giải pháp khác. Có quá nhiều biến trong đó thực hiện chỉnh sửa cho dự án đó cho 1 giải pháp hoàn toàn phá vỡ một cái gì đó trong một giải pháp khác. Sau đó, bằng cách khắc phục vấn đề đó, bạn sẽ phá vỡ giải pháp ban đầu. Lót, rửa sạch, lặp lại.

Khi loại phụ thuộc này rò rỉ vào nhiều giải pháp, tôi muốn tách mã phụ thuộc vào giải pháp OWN của nó và tạo một thư viện hộp đen sau đó được đưa vào làm tài liệu tham khảo. Tôi nghĩ rằng các giải pháp của bạn đã được đan xen để việc gỡ lỗi có thể được thực hiện tất cả các cách vào dự án chia sẻ cho mọi giải pháp. Nếu thư viện được xây dựng và kiểm tra đúng cách, loại gỡ lỗi này thực sự không cần thiết. Thư viện phải có khả năng tự đứng vững và cần được kiểm tra kỹ lưỡng để kỳ vọng của bất kỳ dự án tiêu dùng nào sẽ được đáp ứng một cách nhất quán.


3
Bên cạnh đó, refactoring là dễ dàng như vậy những ngày này, vì vậy nếu bạn làm cảm giác rằng một số spur-of-the-thời điểm thay đổi là đủ quan trọng để thực hiện trong các thư viện riêng của mình, bạn có thể làm cho nó dự án ứng dụng của bạn hiện nay và hợp nhất nó vào thư viện sau , khi bạn ít bị phân tâm bởi nhiệm vụ hiện tại của mình và có thời gian để thực hiện kiểm tra thích hợp.
Aaronaught

@Aaronaught: +1 đến đó.
Joel Etherton

5

Tôi thực sự đã tổ chức các cấu trúc TFS như vậy mà bạn đang đề cập và trong khi nó đưa ra những thách thức độc đáo cho CI, nó có một số lợi ích khác nhau. Một điều rõ ràng là nó hỗ trợ và khuyến khích thành phần hóa phù hợp vào các dự án .NET riêng biệt và do đó hỗ trợ TDD tốt bằng cách khuyến khích bảo hiểm thử nghiệm 100%. Ngay lập tức tôi nhận thấy một vài vấn đề mà bạn có thể giải quyết.

đôi khi một dự án trong giải pháp A chỉ tham chiếu dll trực tiếp từ thư mục đầu ra của dự án được lưu trữ trong giải pháp B, đôi khi dự án chỉ được đưa vào trực tiếp ngay cả khi nó nằm trong FAR trong cấu trúc thư mục.

Tham chiếu nhị phân đến đầu ra của các thư mục khác không phải là một cách tiếp cận tốt và cũng trở thành một cách tiếp cận tồi khi xen kẽ với các tham chiếu dự án. Cố gắng thực hiện cái này hay cái khác, tốt nhất là thay đổi các tham chiếu nhị phân của bạn thành các giới hạn dự án để đảm bảo tính nhất quán. Tại thời điểm này, mỗi Giải pháp có thể biểu thị một lớp ứng dụng hoặc ứng dụng có thể xây dựng duy nhất, (Ví dụ: SuperApp.sln, OtherAppService.sln, OtherAppPftimeationTier.sln).

Để xây dựng TẤT CẢ các dự án, tôi cũng khuyên bạn nên tạo Giải pháp tổng thể. Giải pháp tổng thể sẽ có các tham chiếu dự án cho mọi thứ và về cơ bản tồn tại vì lợi ích duy nhất là có một lệnh xây dựng duy nhất xử lý tất cả các dự án trong bộ ứng dụng. Các nhà phát triển không nên sử dụng Giải pháp tổng thể để phát triển hoặc gỡ lỗi tích cực. Điều này làm cho việc lắp ráp các tạo tác xây dựng dễ dàng hơn rất nhiều.

Triển khai sau đó có thể được thực hiện với một tập lệnh đơn giản, powershell hoặc Perl. Điều này về cơ bản sẽ xây dựng giải pháp phù hợp hoặc giải pháp Master và sau đó triển khai mọi thứ vào các môi trường thích hợp. Điều này có thể dễ dàng tích hợp vào bất kỳ máy chủ CI nào nếu được thực hiện đúng.

• Cách tạo điều kiện chia sẻ logic nghiệp vụ giữa các tạo phẩm triển khai riêng biệt

Tạo một dự án cho logic kinh doanh chung hoặc có mối quan tâm tốt hơn cho logic kinh doanh toàn cầu hoặc phổ quát hơn. Tất cả các giải pháp có thể triển khai muốn tham chiếu điều này nên làm như vậy bằng tham chiếu dự án.

Khi tổ chức mã của bạn trong TFS, việc đạt được điều này trở nên dễ dàng hơn bằng cách giữ các dự án chung hoặc chia sẻ ở mức cao hơn trong cây thư mục.

Khi sử dụng trang web của chúng tôi, bạn xác nhận rằng bạn đã đọc và hiểu Chính sách cookieChính sách bảo mật của chúng tôi.
Licensed under cc by-sa 3.0 with attribution required.