Namespace dan pedoman nama kelas

15

Saya mengalami masalah dalam memberi nama kelas dan layanan saya dengan benar ketika utils dan kelas bantuan lainnya terlibat.

Bagaimana Anda menyusun yang berikut:

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

dll ...

Saya memiliki beberapa layanan dengan kebutuhan yang sama dengan layanan di atas. Satu pemikiran adalah untuk memisahkan semua ini menjadi namespace yang cocok, membuatnya terlihat seperti ini:

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

dan seterusnya. Setiap namespace tentu saja folder terpisah. Tapi ini tidak terasa 100%, karena mungkin ada lebih banyak DateValidatorsdi layanan lain, yang dapat dengan mudah menyebabkan referensi yang tidak diinginkan.

Dan juga Services.EventService.EventService.csmenyertakan nama kelas di namespace, yang juga tidak bagus. Anda bisa menggunakan Services.Event.EventService.cs, tetapi tentu saja sudah ada entitas dengan nama itu.

Ini adalah model domain.

c# architecture

— Mattias
sumber

"Saya memiliki beberapa layanan dengan kebutuhan yang sama dengan layanan di atas." Apakah ini berarti bahwa beberapa layanan menggunakan kode di atas, atau bahwa beberapa layanan perlu menyediakan versi mereka sendiri mengikuti pola yang sama?

— Nathanael

Bahwa mereka menyediakan versi mereka sendiri dari pola yang sama

— Mattias

5

Saya pikir satu-satunya hal terbesar yang dapat Anda lakukan untuk meningkatkan namespace Anda di sini adalah menghapus Servicedari EventServicenamespace Anda . Saya juga menyesuaikan ruang nama agar lebih seperti ini:

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

Saya masih berpikir itu bisa menggunakan beberapa peningkatan.

Saya dulu suka ruang nama, tapi saat ini saya pikir lebih sedikit lebih. Mendalam ruang nama Anda dengan bersarang dapat membuat kode Anda terlalu bertele-tele, dan memecah banyak hal akan mengurangi kemampuan Anda untuk mendapatkan warisan. Dalam kode Anda misalnya, sebuah DateValidatorkelas dapat dengan mudah digunakan di tempat lain, sehingga seharusnya tidak memiliki banyak ruang nama di atasnya, karena layanan selain EventService sekarang dapat memanfaatkan kelas DateValidator. Hal yang sama berlaku untuk metode ekstensi. Tidak ada waktu (yang dapat saya lihat) di mana Anda perlu melihat semua metode ekstensi Anda pada saat yang sama, oleh karena itu lebih masuk akal untuk mengelompokkannya dengan hal yang berkaitan. Dalam hal ini, EventExtensionsmungkin tautan ke Anda EventService, jadi secara logis mereka harus duduk bersama menurut pendapat saya.

— Karl Nicoll
sumber

Proyek ini terlalu besar untuk tidak memecahnya ke tingkat tertentu. DateValidator di bawah namespace acara hanya menangani kasus khusus acara, dan karenanya tidak dapat digunakan di tempat lain. Saya suka Layanan. Acara . Layanan Acara . Bagaimana mungkin aku tidak memikirkan itu. Saya pikir ini waktunya untuk refactoring!

— Mattias

@Mattias - Itu adil. Sejauh yang saya bisa lihat, penamaan (di luar pedoman dasar seperti yang Saeed sebutkan di bawah) cukup banyak hanya masalah selera.

— Karl Nicoll

5

Mengapa Anda tidak membaca Pedoman Penamaan Umum dan Panduan Penamaan Namespace dari Microsoft untuk mengikuti pola universal?

Saya pikir formula ini <Company>.(<Product>|<Technology>)[.<Feature>][.<Subnamespace>]berfungsi dengan baik.

— Saeed Neamati
sumber

2

Desain namespace yang tepat akan mempertimbangkan desain logis dan fisik.

Meskipun dasar pemikiran untuk ruang nama sebagian besar untuk mencegah bentrokan nama antara objek dan nama metode, itu telah menjadi elemen penting dalam arsitektur solusi keseluruhan dan desain. Anda tidak hanya ingin hierarki konseptual dan desain logis Anda masuk akal, Anda mungkin juga ingin kode Anda dikemas secara rapi di perpustakaan yang dirancang dengan baik dan mudah digunakan kembali yang dapat dengan mudah digabungkan ke dalam proyek dan produk lain nanti. Itu mungkin lebih merupakan hasil yang diinginkan dari desain fisik yang baik.

Lihatlah .NET Framework dan bagaimana unit fungsionalitas terkait diberikan kepada Anda dalam rakitan yang berukuran cukup. Anda dapat memasukkan referensi dan pernyataan menggunakan dan tiba-tiba Anda memiliki fungsi yang relevan tersedia tanpa harus menyeret sejumlah wastafel dapur. Ini karena desain fisik .NET Framework — termasuk penempatan nama yang cerdas — telah mengemas kode yang terkait secara logis dalam unit yang dapat digunakan yang terkait secara fisik. Dengan membuat pemetaan yang sangat baik antara ruang nama dan majelis, arsitek dan pengembang Microsoft .NET framework telah membuat pekerjaan Anda jauh lebih mudah (tentu saja beberapa orang mungkin berpendapat sebaliknya, tapi saya agak senang dengan apa yang mereka lakukan).

Namespaceing dalam C # agak sewenang-wenang, sungguh. Anda dapat menempatkan ruang nama di tempat-tempat paling aneh, di majelis yang jauh dari satu sama lain. Setiap disiplin yang membantu dalam bidang ini benar-benar merupakan kontribusi pribadi Anda terhadap produk perangkat lunak yang terorganisir dengan baik. Saya tidak akan berani memberi tahu Anda apa yang harus dilakukan dalam setiap kasus. Apa yang ingin saya capai, dalam jawaban ini, adalah membuat Anda berpikir tentang desain fisik serta desain logis ketika Anda mendefinisikan ruang nama Anda. Semakin Anda menjaga hal-hal yang terkait secara logis dan disebarkan (secara fisik), hal-hal yang lebih mudah nantinya, baik untuk Anda dan orang lain yang mungkin perlu berurusan dengan kode Anda suatu hari nanti.

Jadi, harap pikirkan tentang bagaimana kode Anda akan dikemas dalam rakitan dan komponen ketika Anda menyelesaikan masalah penempatan nama Anda!

— John Tobler
sumber