Quản lý và cấu trúc của dự án .NET đang phát triển

Question

Chúng tôi đang xây dựng nền tảng phần mềm .NET để tự động hóa thử nghiệm để sử dụng trong nhà tại công ty của chúng tôi.

Ứng dụng này bao gồm một thành phần GUI (WinForms) và nhiều "Hành động" khác đang được nạp động vào nó để được thực thi.

Có khoảng ~ 100 dự án hành động đã có, với con số này tăng lên. Một số dự án này phụ thuộc lẫn nhau vào các dự án khác và v.v.

Tất cả các hành động được tải phải tham chiếu dll "SDK" của chúng tôi cho các hoạt động khác nhau (kết quả cho ứng dụng chính, ghi nhật ký, v.v.).

Với thiết kế tương đối đơn giản này, chúng ta đang phải đối mặt với một số quyết định quản lý mà chúng tôi muốn để giải quyết một cách tốt nhất:

1. nên hành động ("plugins") tham khảo kết quả dự án SDK của chúng tôi, hoặc một số được biết đến phiên bản ổn định của nó? Ví dụ, khi phát triển một ứng dụng lớn (MS Office chỉ cho ví dụ), không phải tất cả các nhóm làm việc với mã nguồn cho tất cả các thành phần một cách tự nhiên.

Giải pháp tốt nhất cho thứ gì đó như thế này? và tại sao?

1. Làm cách nào để xác minh chính xác rằng tất cả các phụ thuộc cần thiết (thư viện của bên thứ ba chẳng hạn) thực sự được lấy từ vị trí chính xác?

Thực tiễn phổ biến trong trường hợp quản lý vô số dự án được liên kết ở giữa là gì? có lời khuyên nào để làm như vậy không?

Answer 1

Đây là sự cố không có câu trả lời rõ ràng, nhưng ...

Có hai đường dẫn bạn có thể thực hiện. Một hệ thống kết hợp mạnh mẽ hoặc một hệ thống kết hợp lỏng lẻo.

Đối với một hệ thống mạnh mẽ, tôi có thể đề xuất hai thư mục cho tệp nhị phân: thư mục bên thứ 3 và thư mục chứa các tệp DLL mà bạn xây dựng mà các nhà phát triển khác có thể tham khảo. Các bên thứ ba DLLs (bên ngoài công ty của bạn) nên được đặt trong kiểm soát nguồn để tất cả các nhà phát triển tham khảo cùng một phiên bản của bên thứ ba DLL từ cùng một vị trí này tránh máy phát triển không nhất quán và có vấn đề cài đặt phần mềm của bên thứ 3 trên mỗi máy. Các DLL trong nhà không nên được tham chiếu trong điều khiển nguồn và nên được xây dựng trên mỗi máy phát triển thông qua một tập tin batch xây dựng tự động hoặc tương tự. Trong bước xây dựng, bạn có thể sao chép tất cả chúng vào cùng một thư mục và miễn là các nhà phát triển có được quyền kiểm soát và xây dựng nguồn mới nhất, mọi người đều có cùng một DLL từ bên trong công ty của bạn.

Ví dụ, tải mới nhất, xây dựng (sử dụng tệp lô để xây dựng tất cả các dự án cần thiết), và sau đó làm bước đăng bài sao chép kết quả đầu ra thành phổ biến. Bây giờ tất cả các dự án khác của bạn có thể tham khảo các tệp DLL chung và DLL của bên thứ ba từ cùng một vị trí và mọi người đều nhất quán.

Vấn đề là các tham chiếu được ghép mạnh, do đó, các thay đổi đôi khi có thể có vấn đề nếu không được truyền đạt đúng cách.

Một hệ thống kết hợp lỏng lẻo sử dụng một khung như MEF (Khung mở rộng được quản lý) và các thành phần của bạn tham chiếu "DLL hợp đồng" xác định giao diện cho các thành phần của bạn.Dự án tham chiếu giao diện hoặc hợp đồng DLL và không thực sự quan tâm đến việc thực hiện và sau đó MEF quản lý các plugin cho bạn.

Trong trường hợp này, bạn tham khảo DLL giao diện nhưng không thực sự là DLL thực hiện.

Ví dụ: giả sử tôi có giao diện gọi là ILog với phương thức có tên LogMessage.

private ILog _logger; 
_logger.LogMessage(); 

Vì vậy, trong trường hợp được ghép nối mạnh: Hành động.DLL tham chiếu Logger.DLL trực tiếp.

Trong trường hợp kết hợp lỏng lẻo Action.DLL tham chiếu ILog.DLL (chỉ giao diện). Logger.DLL triển khai thực hiện ILog.DLL. Nhưng Action.DLL không có tham chiếu đến Logger.DLL trực tiếp.

Bây giờ tôi có thể có bất kỳ số lượng tệp DLL nào ngụ ý giao diện ILog, nhưng Action.DLL không trực tiếp tham chiếu chúng. Đó là khá mát mẻ và một trong những tính năng thú vị hơn của MEF và khớp nối lỏng nói chung, khả năng không có phụ thuộc.

Cách bạn chọn, dù theo cách nào cũng được chấp nhận, tôi nghĩ ý tưởng được kết hợp lỏng lẻo phù hợp với kịch bản của bạn là tốt nhất vì các nhóm sẽ chỉ biết hợp đồng so với triển khai thực tế.

Tôi sẽ không có một hợp đồng DLL lớn, tôi sẽ thử và ngắt các giao diện thành các nhóm hợp lý. Ví dụ, đăng nhập có vẻ như một loại tiện ích của giao thoa, vì vậy tôi sẽ tạo ra một DLL hợp đồng tiện ích với một giao diện ILog. Cách chia nhỏ tùy thuộc vào những gì bạn đang cố gắng làm. Hoặc mỗi giao diện có thể là một hợp đồng DLL, nhưng có lẽ đó là một chút cực đoan.

Answer 2

Đây là một chủ đề khá phức tạp, đặc biệt là trong .NET land. Tôi không biết về giải pháp "tốt nhất", nhưng tôi sẽ giải thích cách chúng tôi quản lý nó; có lẽ bạn sẽ hữu ích cho chính mình.

Điều này cho phép bạn xây dựng các hệ thống lớn với nhiều dự án được liên kết nhưng gặp phải nhiều vấn đề phức tạp. Như tôi nghĩ, bất kỳ giải pháp nào thuộc loại này.

Đầu tiên: cấu trúc vật lý (chúng tôi sử dụng SVN).

• Có một rễ kiểm soát nguồn cho từng dự án
• Mỗi dự án có thân riêng của mình, chi nhánh và các thẻ
• Thư mục thân cây có một phiên bản \ src và \ build thư mục, và một không phiên bản \ thư mục lib Thư mục \ lib chứa các tệp nhị phân để tham chiếu. Những tệp nhị phân đó có thể là thư viện của bên thứ ba hoặc các dự án khác mà bạn cần liên kết đến (ví dụ: SDK của bạn). Tất cả các tệp nhị phân trong \ lib đến từ kho lưu trữ ivy của doanh nghiệp (xem http://ant.apache.org/ivy/). Có rất nhiều phong trào những ngày này trong NET đất liên quan đến NuGet, vì vậy bạn có thể kiểm tra xem ra quá.

Thư mục \ build phiên bản của bạn có chứa tập lệnh xây dựng, ví dụ để nhận các tệp nhị phân từ ivy, xuất bản dự án của bạn lên ivy hoặc biên dịch từng dự án. Họ cũng sẽ có ích khi bạn muốn chỉ một máy chủ tích hợp liên tục tại mỗi dự án của bạn.

Thứ hai: Để xác định nơi phụ thuộc đến từ

trả lời: Họ đến từ kho ivy của bạn (nó có thể đơn giản như một hệ thống tập tin mạng chia sẻ). Bạn đã tạo kho lưu trữ, do đó bạn có quyền kiểm soát nội dung của nó. Hãy rất cẩn thận với các tệp nhị phân của bên thứ ba được cài đặt trong GAC. Visual Studio là một nỗi đau trong^^ để đối phó với điều này.

Cụ thể:

Làm thế nào để đúng cách xác minh rằng tất cả cần thiết phụ thuộc (thư viện của bên thứ 3 cho chẳng hạn) đang thực sự lấy từ đúng vị trí?

Ivy mang lại cho bạn sự linh hoạt tuyệt vời với các phụ thuộc và nó cũng giải quyết các phụ thuộc transitive; ví dụ: bạn có thể phụ thuộc vào SDK rev = "1. +" status = "latest.release" có nghĩa là "bản phát hành SDK 1.x ổn định mới nhất hoặc trên SDK rev =" 2. + "status =" mới nhất. tích hợp "có nghĩa là bản nhị phân có sẵn mới nhất của 2.x SDK (có thể được tạo từ một bản dựng tích hợp liên tục).

Vì vậy, bạn sẽ luôn phụ thuộc vào các tệp nhị phân đã biên soạn, không bao giờ xuất ra dự án. Các phần phụ thuộc của bên thứ ba có thể sẽ được đưa vào như transitive khi SDK của bạn

Điều này cũng có nghĩa là số lượng mã trong các dự án của bạn sẽ nhỏ như bạn cần có giải pháp Visual Studio khả thi. có nghĩa là các công cụ tái cấu trúc như ReSharper sẽ ít hữu ích hơn nhiều. xây dựng kịch bản xây dựng và chiến lược phân nhánh của bạn. Điều đó phụ thuộc rất nhiều vào logic của các thành phần của bạn.

Đây là tổng quan ngắn gọn, nếu bạn nghĩ đây là thứ bạn muốn tôi có thể mở rộng câu trả lời. Chúc may mắn; các hệ sinh thái .NET, và Visual Studio nói riêng, không thực sự nghĩ rằng làm việc như thế này.