Giao diện lớp ở đâu nên được đặt trong thư viện lớp .NET?

Question

Tôi tò mò về ý kiến ​​/ thực hành của các nhà phát triển về các giao diện lớp học nên được đặt trong thư viện lớp .NET ở đâu. Chúng có nên được chứa trong thư viện riêng của chúng trong giải pháp, ví dụ: MyCompany.AccountPackage.Interfaces không?

Nếu chúng có không gian tên riêng, ví dụ: MyCompany.AccountPackage.MasterAccounts.Interfaces?

Bất kỳ suy nghĩ/ý kiến ​​nào khác được đánh giá cao?

Có hướng dẫn hay nào chứng minh cách cấu trúc thư viện .Net (hoặc thậm chí tốt hơn, giải pháp), hiển thị nói chung, các lớp/giao diện nào thường được hiển thị trong thư viện chuẩn.

Cảm ơn, d.

Answer 1

Câu trả lời ngắn:

Giao diện phải gần nơi chúng được triển khai.

Ít nhất một số BCL thực hiện việc này - ví dụ: IEnumerable<T> sống trong không gian tên System.Collections.Generic.

---

Hơi còn câu trả lời:

Nó phụ thuộc vào những gì mục đích của giao diện là.

Có phải cung cấp giao diện plug-in (a la la mô hình nhà cung cấp hoặc MEF) cho bên thứ ba không?

Nếu vậy, một hội đồng riêng biệt có thể có ý nghĩa, vì vậy tất cả những gì cần phải được nhập khẩu bởi bên thứ ba là hội đồng này.

Nội bộ, để kiểm tra và mục đích IoC?

Tôi cho rằng việc giữ cho nó gần với việc triển khai có ý nghĩa, có tổ chức và giúp giữ mã đồng bộ với các giao diện.

Answer 2

Tham khảo sau bài:

Proper .NET DLL structure for app

Và, nói chung là cố gắng trả lời câu hỏi sau:

1. các giao diện sẽ được sử dụng bởi nhiều hội?

2. Bạn có thể giảm không. của hội đồng và tài liệu tham khảo?

3. Bạn đang cố gắng bao gồm các giao diện không liên quan vào một assembly, chỉ để giảm số lượng dll?

4. Bạn có nghĩ về khả năng mở rộng và bảo trì không?

Answer 3

Đó là câu trả lời khá theo ngữ cảnh ở chỗ nó phụ thuộc vào giao diện và cách chúng phù hợp với kiến ​​trúc thư viện của bạn.

Object Model

Theo tôi, nếu bạn đang tạo một số hình thức của mô hình đối tượng, bạn nên đặt các giao diện đại diện cho mô hình đối tượng trong một dự án trong một assembly. Bằng cách này, các tham chiếu đến các giao diện có thể được phân phối lại và mã hóa mà không phải lo lắng về việc triển khai thực tế, có thể khác nhau. Nó cũng cho phép bạn cung cấp một triển khai ban đầu của mô hình đối tượng, trong khi để nó mở để thực hiện lại bởi người khác (có lẽ để hỗ trợ một nền tảng mới hoặc phần mềm liên quan).

Generic Sử dụng

Nếu bạn đang có ý định vào việc tạo ra một giao diện tương tự như tìm thấy trong System.Collections.Generic namespace .NET, mà sẽ được tái sử dụng ở nhiều nơi; sau đó tôi sẽ đề nghị đặt nó xuống thấp đủ để nhiều dự án có thể truy cập và thực hiện giao diện. Tuy nhiên, điều này không có nghĩa là bạn không thể tự thực hiện giao diện trong cùng một dự án. Trong trường hợp đó, tất cả phụ thuộc vào ý định của bạn trong hội đồng đó.

Sử dụng khác

sử dụng khác có thể là một số hệ thống tương tác cơ sở dữ liệu, nơi mà bạn có một giao diện định nghĩa một số tương tác bằng cơ sở dữ liệu, nhưng bạn có thể có hai hay nhiều hiện thực của nó. Ví dụ, bạn có thể có một tương tác cụ thể với cơ sở dữ liệu Microsoft Access và một tương tác với cơ sở dữ liệu Sql. Trong trường hợp này, nó sẽ là khả thi để cung cấp (các) giao diện và việc triển khai của bạn trong cùng một hội đồng.

Tất cả những gì được nói, tất cả đều phụ thuộc vào tình huống và mục đích sử dụng. Cách tốt nhất mà tôi đã tìm thấy để xác định đó là gì, là tạo ra một phiên bản nguyên mẫu của hội đồng và xem cách bạn có thể cần phải sử dụng nó.

Answer 4

Như trong hầu hết các trường hợp: tùy theo điều kiện.

Nhưng trong 99% tất cả các trường hợp, tôi đặt giao diện vào các hội đồng của riêng mình, được nhóm thành các đơn vị lô-gic để ngăn chặn các phụ thuộc giao diện chặt chẽ. Trong những ngày trước, tôi chỉ đặt nó ở nơi triển khai đầu tiên. Điều này đã trở thành một mớ hỗn độn chặt chẽ mà không thể chia ra sau.

Nếu bạn thực hành/cố gắng ghép nối lỏng lẻo, tôi khuyên bạn nên di chuyển các giao diện để tách riêng các cụm. tôi thích để chỉ bao gồm:

• giao diện,
• enumerations
• hằng
• phương pháp khuyến nông cho các giao diện (không phụ thuộc vào việc triển khai cụ thể)
• "ổn định" các lớp học và cấu trúc (ví dụ:những người sẽ không bao giờ thay đổi hoặc được thừa hưởng)

thành "hội giao diện" và chỉ tham khảo:

• khác "giao diện hội"
• "công cụ lắp ráp" (mà nên themself chỉ chứa các công cụ ổn định như các phương pháp mở rộng, hằng số)

Điều này không áp dụng cho các giao diện được sử dụng trong nội bộ chỉ được sử dụng trong một assembly (sẽ là 1% giao diện).

Việc thực hiện duy nhất có thể được đưa vào lắp ráp giống như giao diện chính nó là một, rằng:

• không dựa vào lắp ráp phi giao diện khác (bạn không muốn bao gồm công cụ để sử dụng một hội đồng giao diện chỉ cần thiết cho một triển khai mà bạn không muốn sử dụng).
• là một số loại mặc định hoặc không-op thực hiện

Các "thực hiện lắp ráp" chỉ nên được tham chiếu trong lắp ráp chính, hội đồng khác chỉ bao gồm lắp ráp giao diện. Điều này cũng đảm bảo rằng bạn không sử dụng trực tiếp triển khai hoặc kiểm tra xem giao diện có thực hiện đặc biệt này hay không.

Tại sao? Bằng cách này, hội đồng của bạn chỉ dựa vào các hội đồng ổn định và không được kết hợp chặt chẽ. Đây cũng là cách ưu tiên nếu bạn định sử dụng tiêm phụ thuộc.

Không gian tên:

Bạn nên đặt các triển khai trong không gian tên con của giao diện. Vì vậy, để lấy ví dụ của bạn, tôi muốn đề nghị:

• đặt giao diện trong MyCompany.AccountPackage.MasterAccounts
• đặt phương pháp khuyến nông, công cụ ổn định khác cho giao diện này cũng trong MyCompany.AccountPackage.MasterAccounts
• đặt một thực hiện trong một tên đúng không gian tên phụ MyCompany.AccountPackage.MasterAccounts.SQLMasterAccounts hoặc chỉ MyCompany.AccountPackage.MasterAccounts.Implementation.

Tại sao?

Từ phía triển khai, điều này có nghĩa là bạn nhận được tất cả giao diện và tiện ích mở rộng mà không phải sử dụng using MyCompany.AccountPackage.MasterAccounts.Interfaces. Từ phía khách hàng, điều này có nghĩa là bạn sẽ được bảo vệ khỏi quá nhiều tùy chọn từ intellisense trong các assembly triển khai (không nên bao gồm các assembly khác), nhưng dễ dàng truy cập vào các cài đặt trong assembly chính, nơi bạn chọn triển khai cụ thể để sử dụng.