Không gian tên và hướng dẫn tên lớp


15

Tôi gặp vấn đề khi đặt tên cho các lớp và dịch vụ của mình một cách chính xác khi các tiện ích và các lớp trợ giúp khác có liên quan.

Làm thế nào bạn sẽ cấu trúc như sau:

EventService.cs
EventServiceUtils.cs
EventServiceValidators.cs
EventServiceCoordinator.cs

Vân vân...

Tôi có nhiều dịch vụ có cùng nhu cầu như dịch vụ trên. Một suy nghĩ là tách tất cả những thứ này thành một không gian tên phù hợp, làm cho nó trông giống như thế này:

Services.EventService.EventService.cs //(the actual service)
Services.EventService.Validators.DateValidator.cs
Services.EventService.Validators.ParticipantValidator.cs
Services.EventService.Coordinators.ParticipantCoordinator.cs
Services.EventService.ExtensionMethods.Extensions.cs

và như thế. Mỗi không gian tên tất nhiên là một thư mục riêng. Nhưng điều này không cảm thấy 100%, vì có lẽ có nhiều DateValidatorsdịch vụ khác, điều này có thể dễ dàng dẫn đến một tham chiếu không mong muốn.

Và cũng Services.EventService.EventService.csbao gồm tên lớp trong không gian tên, điều này cũng không tốt. Bạn có thể sử dụng Services.Event.EventService.cs, nhưng tất nhiên đã có một thực thể có tên đó.

Đây là mô hình miền.


"Tôi có nhiều dịch vụ có cùng nhu cầu như dịch vụ trên." Điều này có nghĩa là nhiều dịch vụ sử dụng mã trên hoặc nhiều dịch vụ cần cung cấp phiên bản của riêng chúng theo cùng một mẫu?
Nathanael

Rằng họ cung cấp phiên bản riêng của cùng một mẫu
Mattias

Câu trả lời:


5

Tôi nghĩ rằng điều lớn nhất bạn có thể làm để cải thiện không gian tên của mình ở đây là xóa Servicekhỏi EventServicekhông gian tên của bạn . Tôi cũng sẽ điều chỉnh các không gian tên giống như thế này:

Services.Events.EventService.cs //(the actual service)
Services.Events.EventExtensions.cs
Services.Events.ParticipantCoordinator.cs
Services.Validators.DateValidator.cs
Services.Validators.ParticipantValidator.cs

Tôi vẫn nghĩ rằng có thể sử dụng một số cải tiến mặc dù.

Tôi đã từng thích không gian tên, nhưng ngày nay tôi nghĩ ít hơn là nhiều hơn. Việc lồng sâu các không gian tên của bạn có thể làm cho mã của bạn quá dài dòng và phá vỡ mọi thứ để giảm khả năng kế thừa của bạn. Ví dụ, trong mã của bạn, một DateValidatorlớp có thể dễ dàng được sử dụng ở nơi khác, vì vậy nó không nên có nhiều không gian tên phía trên nó, vì các dịch vụ khác ngoài EventService hiện có thể tận dụng lớp DateValidator. Điều tương tự áp dụng cho các phương pháp mở rộng. Không có thời gian (mà tôi có thể thấy) khi bạn cần xem tất cả các phương thức tiện ích mở rộng của mình cùng một lúc, do đó, sẽ hợp lý hơn khi nhóm nó với điều mà nó liên quan. Trong trường hợp này, EventExtensionscó lẽ liên kết đến của bạn EventService, vì vậy về mặt logic, họ nên ngồi lại với nhau theo ý kiến ​​của tôi.


Dự án quá lớn để không phá vỡ nó đến một mức độ nhất định. DateValidator trong không gian tên sự kiện chỉ xử lý các trường hợp cụ thể cho sự kiện và do đó không thể được sử dụng ở nơi khác. Tôi thích Dịch vụ. Sự kiện .EventService. Làm thế nào tôi có thể không nghĩ về điều đó. Tôi nghĩ rằng đã đến lúc cho một số tái cấu trúc!
Mattias

@Mattias - Thật công bằng. Theo như tôi có thể thấy, không gian tên (ngoài các hướng dẫn cơ bản như những hướng dẫn mà Saeed đã đề cập dưới đây) gần như chỉ là vấn đề của hương vị.
Karl Nicoll


2

Thiết kế không gian tên thích hợp sẽ xem xét cả thiết kế logic và vật lý.

Mặc dù lý do ban đầu cho các không gian tên chủ yếu là để ngăn ngừa xung đột tên giữa các tên đối tượng và phương thức, nó đã trở thành một yếu tố quan trọng trong thiết kế và kiến ​​trúc giải pháp tổng thể. Bạn không chỉ muốn hệ thống phân cấp khái niệm và thiết kế logic của mình có ý nghĩa, có lẽ bạn cũng muốn mã của mình được đóng gói gọn gàng trong các thư viện được thiết kế tốt và dễ sử dụng để có thể dễ dàng đưa vào các dự án và sản phẩm khác sau này. Đó có lẽ là kết quả mong muốn của thiết kế vật lý tốt.

Nhìn vào .NET Framework và cách các đơn vị chức năng liên quan được trao cho bạn trong các cụm có kích thước hợp lý. Bạn có thể thả vào một tham chiếu và một tuyên bố sử dụng và đột nhiên bạn có sẵn chức năng liên quan mà không cần phải kéo vào bất kỳ số lượng bồn rửa nhà bếp. Điều này là do thiết kế vật lý của .NET Framework bao gồm cả không gian tên thông minh đã đóng gói mã liên quan logic trong các đơn vị triển khai có liên quan về mặt vật lý. Bằng cách tạo ra một ánh xạ tuyệt vời giữa các không gian tên và các cụm, các kiến ​​trúc sư và nhà phát triển của .NET .NET đã làm cho công việc của bạn dễ dàng hơn đáng kể (tất nhiên một số có thể tranh luận khác, nhưng tôi khá hài lòng với những gì họ đã làm).

Không gian tên trong C # là khá tùy tiện, thực sự. Bạn có thể đặt các không gian tên ở những nơi kỳ lạ nhất, trong các cụm lắp ghép cách xa nhau. Bất kỳ kỷ luật hữu ích nào trong lĩnh vực này thực sự là đóng góp cá nhân của bạn cho một sản phẩm phần mềm được tổ chức tốt. Tôi không dám khuyên bạn chính xác phải làm gì trong từng trường hợp. Điều tôi hy vọng sẽ đạt được, trong câu trả lời này, là khiến bạn suy nghĩ về thiết kế vật lý cũng như thiết kế logic khi bạn xác định không gian tên của mình. Bạn càng giữ mọi thứ liên quan một cách logic và có thể triển khai (về mặt vật lý) thì mọi thứ sẽ dễ dàng hơn sau này, cho cả bạn và cho những người khác có thể cần phải xử lý mã của bạn một ngày nào đó.

Vì vậy, xin vui lòng suy nghĩ về cách mã của bạn sẽ được đóng gói trong các cụm và các thành phần khi bạn giải quyết các vấn đề về không gian tên của bạn!

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.