Các không gian tên .NET

Question

Nền của tôi chủ yếu là một nhà phát triển Java, nhưng gần đây tôi đã làm một số công việc trong .NET. Vì vậy, tôi đã cố gắng để làm một số dự án đơn giản ở nhà để làm việc tốt hơn với .NET. Tôi đã có thể chuyển nhiều kinh nghiệm Java của tôi vào làm việc với .NET (đặc biệt là C#), nhưng điều duy nhất thực sự làm tôi bối rối là các không gian tên.

Tôi biết không gian tên tương tự như gói Java, nhưng từ những gì tôi có thể nói sự khác biệt chính là với gói Java họ sử dụng thư mục tệp thực để hiển thị phân tách, trong khi .NET không có và tất cả các tệp nằm trong một thư mục duy nhất và không gian tên được khai báo đơn giản trong mỗi lớp.

Tôi thấy điều này lạ, bởi vì tôi luôn thấy các gói như là một cách để sắp xếp và nhóm mã liên quan, giúp việc điều hướng và hiểu dễ dàng hơn. Kể từ trong .NET nó không làm việc công việc này theo cách này, làm thêm giờ, dự án xuất hiện quá đông đúc và không dễ dàng điều hướng.

Tôi có thiếu gì đó ở đây không? Tôi phải thế. Tôi có nên chia nhỏ mọi thứ thành các dự án riêng biệt trong giải pháp không? Hoặc là có cách nào tốt hơn để giữ cho các lớp và các tập tin được tổ chức trong một dự án?

Chỉnh sửa: Như Blair đã chỉ ra đây là câu hỏi tương tự, được hỏi here.

Answer 1

Tôi không thể cho rằng đó là phương pháp hay nhất, nhưng tôi thường thấy các tệp được sắp xếp theo thứ bậc thư mục phản ánh không gian tên. Nếu nó phù hợp với mô hình tinh thần của bạn về mã tốt hơn, thì hãy làm như vậy - Tôi không thể nghĩ ra bất kỳ tác hại nào. Chỉ vì mô hình .NET không thực thi các mối quan hệ giữa các không gian tên, các dự án và cấu trúc thư mục không có nghĩa là bạn không thể có các mối quan hệ như vậy nếu bạn muốn.

Tôi muốn một chút bẻ khóa mã thành nhiều dự án hơn bạn cần, vì điều này có thể làm chậm quá trình biên dịch và thêm một chút chi phí khi bạn phải quản lý nhiều hội đồng.

EDIT: Lưu ý rằng câu hỏi này là gần một bản sao của should the folders in a solution match the namespace?

Answer 2

Bạn có thể thêm các thư mục để giải pháp của bạn cho mỗi không gian tên. Trong khi nó vẫn sẽ biên dịch thành một tệp thực thi duy nhất, nó tổ chức các tệp nguồn của bạn và cho (những gì tôi nghĩ là) hiệu ứng mong muốn?

tôi thường thêm một thư mục cho mỗi không gian tên trong dự án của tôi, và làm tổ chúng theo thứ bậc tương tự (MyApp.View.Dialogs ví dụ)

Answer 3

Một VS giải pháp thường chứa một hoặc nhiều dự án. Các dự án Thse có các không gian tên mặc định (thường là không gian tên chỉ là tên của dự án). Thông thường, nếu bạn thêm một thư mục trong dự án, tất cả các lớp trong nó sẽ được đặt tên như sau:

DefaultNamespace.FolderName.ClassName

Tất nhiên, bạn có thể thay đổi không gian tên mặc định của dự án và đặt các lớp của bạn theo bất kỳ cách nào bạn muốn.

Theo thời gian/cách thức chia nhỏ nội dung thành các dự án, đó là vấn đề về trải nghiệm và/hoặc sở thích. Tuy nhiên, bạn hoàn toàn nên chia công cụ thành các dự án trong một giải pháp, để giữ cho dự án của bạn được tổ chức. Nếu quản lý quá nhiều hội đồng trở nên rườm rà (như Blair đề xuất), bạn luôn có thể ILMerge hội đồng của bạn thành một hội đồng duy nhất.Điều tuyệt vời về ILMerge là mặc dù bạn kết thúc với chỉ một hội đồng, tất cả các lớp học của bạn giữ nguyên tên đầy đủ của họ.

Điều quan trọng cũng cần nhớ là giải pháp VS không có dấu hiệu trên mã - tức là. họ không được xây dựng. Giải pháp VS là gì, nhưng là một cách để nhóm các dự án; đó là các dự án được xây dựng và biến thành các tệp DLL.

Cuối cùng, VS cho phép bạn thêm các thư mục "ảo" vào bất kỳ đâu trong giải pháp. Các thư mục này không ánh xạ tới một thư mục trong hệ thống tệp và chỉ được sử dụng làm phương tiện khác để giúp bạn tổ chức các dự án và các tạo tác khác trong giải pháp.

Answer 4

Đúng, trong không gian tên .NET không phụ thuộc vào hệ thống tệp hoặc bất kỳ thứ gì khác. Đó là một lợi thế lớn trong quan điểm của tôi. Ví dụ bạn có thể chia mã của bạn trên các hội đồng khác nhau cho phép phân phối linh hoạt.

Khi làm việc trong Visual Studio, IDE có xu hướng giới thiệu vùng tên mới khi bạn thêm thư mục mới vào dự án cây.

Dưới đây là một liên kết hữu ích từ MSDN:

Namespace Naming Guidelines

Nguyên tắc chung cho việc đặt tên không gian tên là sử dụng tên công ty tiếp theo tên công nghệ và có thể là tính năng và thiết kế như sau.
CompanyName.TechnologyName [.Feature] [. Thiết kế]

Tất nhiên bạn có thể sử dụng không gian tên theo cách bạn tìm thấy phù hợp hơn. Tuy nhiên nếu bạn định chia sẻ mã của mình, tôi khuyên bạn nên đi cùng với các tiêu chuẩn được chấp nhận.

EDIT:

tôi khuyên bạn nên để bất kỳ nhà phát triển .net để có được một bản sao của Framework design guidelines Cuốn sách này sẽ giúp bạn hiểu cách và tại sao .NET được thiết kế.

Answer 5

Không gian tên hoàn toàn là ngữ nghĩa. Trong khi họ thường phản ánh một cấu trúc thư mục, ít nhất là khi sử dụng Visual Studio IDE, họ không cần phải.

Bạn có thể có cùng một không gian tên được tham chiếu trong nhiều thư viện, xấu xí nhưng đúng.

Answer 6

Thật vậy, môi trường .NET cho phép bạn ném mã của mình vào hệ thống tập tin/IDE như spaghetti trên tường.

Điều đó không có nghĩa là phương pháp này là lành mạnh, tuy nhiên. Nói chung, một ý tưởng hay là gắn bó với cách tiếp cận project.foldername.Class đã được đề cập trước đó. Nó cũng là một ý tưởng thực sự tốt để giữ tất cả các lớp từ một không gian tên vào cùng một lớp.

Trong Java, bạn có thể làm những việc như thế này cũng như nhận được tất cả "tính linh hoạt" mà bạn muốn, nhưng các công cụ có xu hướng không khuyến khích nó. Thành thật mà nói, một trong những điều khó hiểu nhất đối với tôi khi được giới thiệu với thế giới .Net chỉ là sự cẩu thả/mâu thuẫn này có thể nhờ vào sự hướng dẫn tương đối nghèo nàn. Mặc dù vậy, việc dễ dàng tổ chức mọi thứ một cách an toàn với một chút suy nghĩ.:)

Answer 7

Tôi luôn coi tổ chức tệp nguồn và chỉ định số nhận dạng cho các lớp và đối tượng là hai vấn đề riêng biệt. Tôi có xu hướng giữ các lớp liên quan theo nhóm, nhưng không phải mọi nhóm nên là một không gian tên. Không gian tên tồn tại (nhiều hơn hoặc ít hơn) để giải quyết vấn đề xung đột tên — trong các ngôn ngữ không gian tên phẳng như C, bạn không thể đi bộ hai chân mà không vấp phải các mã định danh như mycompany_getcurrentdate hoặc MYCGetCurrentDate, vì rủi ro xung đột với một hàm khác trong thư viện của bên thứ ba (hoặc hệ thống) nhỏ hơn nhiều. Nếu bạn đã tạo một gói hoặc không gian tên cho mỗi sự phân tách hợp lý, bạn sẽ nhận được các tên lớp (ví dụ Java) như java.lang.primitivewrapper.numeric.Integer, đó là khá nhiều quá mức cần thiết.

Answer 8

Không gian tên là nhóm hợp lý, trong khi các dự án là một nhóm vật lý.

Tại sao điều này quan trọng? Hãy suy nghĩ về .NET 2.0, 3.0 và 3.5. .NET 3.0 về cơ bản là .NET 2.0 với một số assembly bổ sung, và 3.5 bổ sung thêm một vài assembly nữa. Vì vậy, ví dụ, .NET 3.5 thêm điều khiển DataPager, là một điều khiển web và nên được nhóm trong System.Web.UI.WebControls. Nếu không gian tên và vị trí vật lý giống hệt nhau, thì không thể vì nó nằm trong một hội đồng khác.

Vì vậy, có không gian tên là thực thể lôgic độc lập có nghĩa là bạn có thể có các thành viên của một số nhóm khác nhau được nhóm hợp lý với nhau vì chúng được sử dụng kết hợp với nhau.

(Ngoài ra, không có gì sai với việc bố trí vật lý và logic của bạn khá giống nhau.)

Answer 9

sự khác biệt là không gian tên .net không có gì nhiều để làm với các gói java.

. Không gian tên mạng là hoàn toàn để quản lý phạm vi khai báo và không liên quan gì đến tệp, dự án hoặc vị trí của chúng.

mọi thứ rất đơn giản được khai báo trong một không gian tên cụ thể đều có thể truy cập được khi bạn bao gồm 'đang sử dụng' vào không gian tên đó.

rất dễ dàng.

lựa chọn tên và có hay không/số lượng '.' các seperators bạn sử dụng là hoàn toàn tùy thuộc vào bạn.

VS mặc định thêm tên .foldernam vào không gian tên của bạn chỉ để thử và hữu ích.

bài viết này giải thích không gian tên khá tốt: http://www.blackwasp.co.uk/Namespaces.aspx

Nó cũng có một ví dụ quy ước đặt tên vào giai đoạn cuối, mặc dù ước tên của bạn là cuộc gọi của bạn! ;)

nói rằng, hầu hết những nơi tôi đã làm việc và những người tôi đã làm việc với tên công ty hợp lý, vì nó làm cho tên tệp cho công ty đó tách biệt, (tách biệt với thư viện, nhà cung cấp, nguồn mở khác projcts, vv)