Chia sẻ các lớp hoặc giao diện giữa các dự án khác nhau

Tôi đã tìm kiếm một số câu trả lời trong SO hoặc ở đây, nhưng không có kết quả, đó là lý do tại sao tôi sẽ hỏi bạn.

Giả sử tôi có hai dự án khác nhau - ví dụ: phần máy chủ và phần máy khách của một ứng dụng. Tôi đang phát triển phần của riêng mình, trong khi bạn tôi đang làm phần thứ hai. Nhưng cả hai chúng ta nên sử dụng một số giao diện phổ biến như Userhoặc AccountInfohoặc ChangableAccount... bất cứ điều gì để đảm bảo tính tương thích. Ví dụ: nếu khách hàng gửi dữ liệu Người dùng đến máy chủ thì máy chủ sẽ hoạt động trên cùng một lớp. Tương tự với các giao diện, v.v. Hơn nữa, nếu có bất kỳ thay đổi nào trong giao diện chung, cả hai dự án nên điều chỉnh mã của nó theo tình huống mới.

Giải pháp duy nhất tôi có thể thấy bây giờ là, tạo một dự án bổ sung trong đó tất cả những điều phổ biến được xác định. Chúng tôi, tôi và bạn của tôi, nên thêm dự án này như một sự phụ thuộc vào một dự án chính (máy khách hoặc máy chủ). Dự án chia sẻ có thể được quản lý bởi một số hệ thống kiểm soát phiên bản, vì vậy chúng tôi luôn có trạng thái cập nhật nhất.

Bạn có đề xuất giải pháp nào khác? Làm thế nào những vấn đề như vậy được giải quyết trong các ứng dụng chuyên nghiệp?

tạo một dự án bổ sung trong đó tất cả những điều phổ biến được xác định

Đây là bước đầu tiên chính xác để chia sẻ các phần có thể tái sử dụng - và là phần dễ dàng. Phần khó khăn hơn là quyết định xem hai dự án đang sử dụng thư viện dùng chung có chu kỳ phát hành độc lập (hoặc không) hay không và liệu có thể "dự án A" sử dụng phiên bản 1.0 của lib được chia sẻ của bạn hay không, trong khi dự án B sử dụng phiên bản 2.0 cùng một lúc .

Nếu bạn muốn cái sau có thể, bạn cần có một sơ đồ phiên bản nghiêm ngặt và quản lý phát hành cho thư viện của bạn (và số phiên bản là một phần của tên tệp thư viện, như được đề xuất bởi @RoryHunter). Bạn cũng nên quan tâm về khả năng tương thích ngược trong lib của bạn trong tình huống này. Thư viện của bạn nên được quản lý như một sản phẩm riêng biệt, thêm các bài kiểm tra đơn vị vào đó để đảm bảo các phiên bản khác nhau trong sản xuất sẽ là một ý tưởng hay và một công cụ như Maven cũng có thể có ý nghĩa.

Tuy nhiên, nếu bạn muốn ngăn chặn tình huống đó, bạn nên quản lý "dự án A", "dự án B" và lib của bạn như một dự án chung, với quá trình phát triển, xây dựng và phát hành kết hợp. Điều này sẽ cho phép thay đổi giao diện chung của thư viện chia sẻ nhiều hơn và thường xuyên hơn trong kịch bản đầu tiên. Và bạn sẽ không cần một cái gì đó như Maven hoặc số phiên bản trong tên tệp thư viện. Nhưng sự đánh đổi là A và B không thể được phát triển độc lập nữa.

Giải pháp của bạn là đúng. Đặt mã được chia sẻ vào một dự án khác xây dựng tệp JAR của riêng nó và sử dụng nó trong cả hai dự án. Khi xây dựng tệp JAR, bạn có thể muốn đưa phiên bản vào tên, ví dụ như theo kiểu Debian;

libmyproject-shared-1.0.jar

Nó không ngăn chặn sự cố phiên bản, nhưng nó sẽ giúp. Tôi chưa bao giờ sử dụng Maven, nhưng tôi hiểu nó có thể giúp ích trong tình huống này.

tạo một dự án bổ sung trong đó tất cả những điều phổ biến được xác định

Đó chính xác là cách mà .Net mong bạn làm điều đó.

Tóm tắt các đối tượng này thành một hội thứ ba, và tham chiếu điều này từ cả hai dự án. Tôi khuyên bạn nên làm như Giao diện, sạch hơn, nhưng ...

Xem ra cho serialization:

• Cách duy nhất tôi có thể trực tiếp nối tiếp / giải nén các đối tượng giữa hai chương trình (phải thừa nhận rằng cách đây một thời gian sử dụng Framework 2.0) là cài đặt cụm "chia sẻ" vào Bộ đệm ẩn hội đồng toàn cầu trên cả máy khách và máy chủ. Nếu hội đồng là "cục bộ" cho mỗi dự án, thì Khung công tác đã xem chúng là các Loại riêng biệt và từ chối [nối tiếp] nối tiếp dự án này với dự án khác.
• Và [de] các đối tượng nối tiếp được gõ là Giao diện là một chút "thách thức". Loại ban đầu, không có giao diện dường như không "tạo ra" thông qua "đường ống" nối tiếp, do đó người nhận không biết Loại cụ thể nào sẽ "xây dựng" từ luồng đến.

Như những người khác đã đề xuất, quá trình suy nghĩ của bạn là chính xác. Về chuyên môn, hầu hết sẽ sử dụng một cái gì đó như Maven hoặc Gradle để quản lý các phụ thuộc này một cách hiệu quả.