Haruskah folder dalam solusi cocok dengan namespace?


129

Haruskah folder dalam solusi cocok dengan namespace?

Di salah satu proyek tim saya, kami memiliki perpustakaan kelas yang memiliki banyak sub-folder di proyek.

Nama proyek dan Ruang nama: MyCompany.Project.Section.

Dalam proyek ini, ada beberapa folder yang cocok dengan bagian namespace:

  • Folder Vehiclesmemiliki kelas di MyCompany.Project.Section.Vehiclesnamespace
  • Folder Clothingmemiliki kelas di MyCompany.Project.Section.Clothingnamespace
  • dll.

Di dalam proyek yang sama ini, ada folder jahat lain

  • Folder BusinessObjectsmemiliki kelas di MyCompany.Project.Sectionnamespace

Ada beberapa kasus seperti ini di mana folder dibuat untuk "kenyamanan organisasi".

Pertanyaan saya adalah: Apa standarnya? Di perpustakaan kelas apakah folder biasanya cocok dengan struktur namespace atau apakah itu tas campuran?


9
Catatan: ReSharper akan mengeluh jika ruang nama tidak cocok dengan hierarki folder.
Fred

Jawaban:


77

Juga, perhatikan bahwa jika Anda menggunakan templat bawaan untuk menambahkan kelas ke folder, maka secara default akan diletakkan di namespace yang mencerminkan hierarki folder.

Kelas-kelas akan lebih mudah ditemukan dan itu saja harus menjadi alasan yang cukup baik.

Aturan yang kami ikuti adalah:

  • Nama proyek / perakitan sama dengan namespace root, kecuali untuk akhiran .dll
  • Satu-satunya pengecualian untuk aturan di atas adalah proyek dengan akhir .Core, .Core dilucuti
  • Folder sama dengan ruang nama
  • Satu jenis per file (kelas, struct, enum, delegate, dll.) Membuatnya mudah untuk menemukan file yang tepat

1
+1 untuk "Satu-satunya pengecualian pada aturan di atas adalah proyek dengan akhiran .Core, .Core dilucuti" sendirian. Saya memiliki sebuah MyProject.Core.dllpertemuan dan semua kelas dimulai dengan MyProject.Core. Mengupas .Coresufiks jauh lebih masuk akal.
Luiz Damim

2
Pengecualian lain yang mungkin saya tambahkan adalah Pengecualian. Pengecualian sudah berakhiran dengan 'Pengecualian' sehingga namespace tambahan berlebihan. Itu juga bisa menjadi berantakan memiliki bagian dari namespace dengan kata Exception (dapat menyebabkan System.Exception membingungkan). Namun, mengaturnya ke dalam folder cukup membantu.
phillipwei

55

Tidak.

Saya sudah mencoba kedua metode pada proyek kecil dan besar, baik dengan satu (saya) dan tim pengembang.

Saya menemukan rute paling sederhana dan paling produktif adalah memiliki satu namespace per proyek dan semua kelas masuk ke namespace itu. Anda kemudian bebas untuk meletakkan file kelas ke dalam folder proyek apa pun yang Anda inginkan. Tidak ada masalah tentang menambahkan pernyataan menggunakan di bagian atas file sepanjang waktu karena hanya ada satu namespace.

Sangat penting untuk mengatur file sumber ke dalam folder dan menurut saya itu semua folder harus digunakan. Membutuhkan bahwa folder ini juga memetakan ke ruang nama tidak perlu, menciptakan lebih banyak pekerjaan, dan saya menemukan itu benar-benar berbahaya bagi organisasi karena beban tambahan mendorong disorganisasi.

Ambil peringatan FxCop ini sebagai contoh:

CA1020: Hindari ruang nama dengan beberapa jenis
penyebab: Sebuah ruang nama selain ruang nama global mengandung kurang dari lima jenis https://msdn.microsoft.com/en-gb/library/ms182130.aspx

Peringatan ini mendorong pembuangan file baru ke folder Project.General umum, atau bahkan root proyek sampai Anda memiliki empat kelas yang sama untuk membenarkan membuat folder baru. Akankah itu terjadi?

Menemukan File

Jawaban yang diterima mengatakan, "Kelas-kelas akan lebih mudah ditemukan dan itu saja harus menjadi alasan yang cukup baik."

Saya menduga jawabannya merujuk memiliki beberapa ruang nama dalam proyek yang tidak memetakan ke struktur folder, daripada apa yang saya sarankan yang merupakan proyek dengan ruang nama tunggal.

Dalam kasus apa pun ketika Anda tidak dapat menentukan folder mana file kelas berada dari namespace, Anda dapat menemukannya dengan menggunakan Go To Definition atau kotak pencarian solusi explorer di Visual Studio. Juga ini bukan masalah besar menurut saya. Saya bahkan tidak mengeluarkan 0,1% dari waktu pengembangan saya pada masalah menemukan file untuk membenarkan pengoptimalannya.

Bentrokan nama

Tentu membuat banyak ruang nama memungkinkan proyek memiliki dua kelas dengan nama yang sama. Tetapi apakah itu benar-benar hal yang baik? Apakah mungkin lebih mudah untuk tidak mengizinkan hal itu terjadi? Membiarkan dua kelas dengan nama yang sama menciptakan situasi yang lebih kompleks di mana 90% dari semua waktu bekerja dengan cara tertentu dan kemudian tiba-tiba Anda menemukan Anda memiliki kasing khusus. Katakanlah Anda memiliki dua kelas Rectangle yang didefinisikan dalam ruang nama yang terpisah:

  • class Project1.Image.Rectangle
  • kelas Project1.Window.Rectangle

Dimungkinkan untuk mencapai suatu masalah bahwa file sumber harus menyertakan kedua ruang nama. Sekarang Anda harus menulis namespace lengkap di mana saja di file itu:

var rectangle = new Project1.Window.Rectangle();

Atau mengacaukan dengan beberapa pernyataan menggunakan jahat:

using Rectangle = Project1.Window.Rectangle;

Dengan satu namespace dalam proyek Anda, Anda dipaksa untuk membuat yang berbeda, dan saya berpendapat lebih deskriptif, nama-nama seperti ini:

  • class Project1.ImageRectangle
  • kelas Project1.WindowRectangle

Dan penggunaannya sama di mana-mana, Anda tidak harus berurusan dengan kasus khusus ketika file menggunakan kedua jenis.

menggunakan pernyataan

using Project1.General;  
using Project1.Image;  
using Project1.Window;  
using Project1.Window.Controls;  
using Project1.Shapes;  
using Project1.Input;  
using Project1.Data;  

vs.

using Project1;

Kemudahan tidak harus menambahkan ruang nama sepanjang waktu saat menulis kode. Ini bukan waktu yang dibutuhkan, ini adalah penghentian karena harus melakukannya dan hanya mengisi file dengan banyak menggunakan pernyataan - untuk apa? Apakah itu layak?

Mengubah struktur folder proyek

Jika folder dipetakan ke namespaces maka path folder proyek secara efektif dikodekan ke dalam setiap file sumber. Ini berarti setiap perubahan nama atau pemindahan file atau folder dalam proyek membutuhkan konten file aktual untuk berubah. Baik deklarasi namespace file dalam folder itu dan menggunakan pernyataan dalam sejumlah file lain yang mereferensikan kelas dalam folder itu. Sementara perubahan itu sendiri sepele dengan tooling, biasanya menghasilkan komit besar yang terdiri dari banyak file yang kelasnya bahkan belum berubah.

Dengan namespace tunggal dalam proyek Anda dapat mengubah struktur folder proyek namun Anda inginkan tanpa file sumber itu sendiri sedang dimodifikasi.

Visual Studio secara otomatis memetakan namespace file baru ke folder proyek yang dibuatnya

Sayangnya, tapi saya merasa kesulitan untuk memperbaiki namespace lebih mudah daripada berurusan dengan mereka. Saya juga sudah terbiasa menyalin file yang sudah ada daripada menggunakan Add-> New.

Intellisense dan Object Browser

Manfaat terbesar menurut saya menggunakan banyak ruang nama dalam proyek-proyek besar adalah memiliki organisasi ekstra saat melihat kelas dalam alat apa pun yang menampilkan kelas dalam hierarki ruang nama. Bahkan dokumentasi. Jelas memiliki hanya satu namespace dalam hasil proyek di semua kelas yang ditampilkan dalam satu daftar daripada dibagi ke dalam kategori. Namun secara pribadi saya tidak pernah bingung atau tertunda karena kekurangan ini jadi saya tidak menemukan manfaat yang cukup besar untuk membenarkan beberapa ruang nama.

Meskipun jika saya sedang menulis perpustakaan kelas publik yang besar maka saya mungkin akan menggunakan banyak ruang nama dalam proyek sehingga perakitan terlihat rapi dalam perkakas dan dokumentasi.


30
Ini sejujurnya salah satu solusi paling buruk yang pernah saya dengar. Jika Anda bekerja pada proyek halo kecil dunia maka saran ini berfungsi, tetapi bayangkan Anda memiliki 1000+ file .cs. Itu akan menyebabkan begitu banyak masalah sehingga saya tidak tahu harus mulai dari mana.
BentOnCoding

10
"Tapi bayangkan Anda memiliki 1000+ file .cs". Saya telah bekerja di proyek sebesar itu dengan satu namespace. Tidak apa-apa. Menurut Anda bencana apa yang akan terjadi?
Weyland Yutani

14
+1 untuk dipikirkan. Saya tidak berpikir saya siap untuk mengurangi ruang nama saya menjadi satu per proyek tetapi setelah bekerja pada kerangka kerja yang besar saya mengeksplorasi mengurangi jumlah ruang nama untuk mengurangi jumlah menggunakan pernyataan dan untuk membantu ditemukannya metode ekstensi. Saya pikir jawaban ini memberikan beberapa pemikiran yang baik. Terima kasih.
Lee Gunn

3
@WeylandYutani saya tahu saya terlambat tetapi saya perlu menyebutkan bahwa kalimat ini: you can find it by using Go To Definition or the search solution explorer box in Visual Studiotidak selalu benar. Cobalah banyak warisan dan Antarmuka ... semoga berhasil menemukan file yang tepat.
Emmanuel M.

11
Ini adalah salah satu saran terbaik yang pernah saya lihat. Ruang nama hanya untuk resolusi konflik, bukan pengorganisasian kelas. Gunakan ruang nama hanya di mana masuk akal untuk menggunakannya, seperti di mana Anda berharap memiliki konflik penamaan dengan proyek lain yang mungkin menggunakan proyek Anda, memungkinkan ruang nama tertentu untuk dimasukkan atau dikecualikan dengan menggunakan pernyataan. Mengerikan memiliki proyek dengan 3 atau 4 ruang nama atau lebih yang sering digunakan, karena selalu menghasilkan jumlah pernyataan penggunaan yang konyol yang perlu Anda tambahkan dan tambahkan dan tambahkan dan tambahkan. Pisahkan proyek Anda.
Triynko

31

Saya pikir standar, dalam. NET, adalah untuk mencoba melakukannya bila memungkinkan, tetapi tidak untuk membuat struktur yang tidak perlu hanya untuk mematuhinya sebagai aturan keras. Tidak ada proyek saya mengikuti namespace == aturan struktur 100% dari waktu, kadang-kadang lebih bersih / lebih baik untuk keluar dari aturan tersebut.

Di Jawa Anda tidak punya pilihan. Saya menyebutnya kasus klasik tentang apa yang berhasil dalam teori vs apa yang berhasil dalam praktik.


1
Saya akan mengatakan "lakukan ketika Anda benar-benar ingin sesuatu berada di namespace sendiri". Itu harus menjadi keputusan sadar. Jika proyek Anda terisolasi dengan baik, itu harus satu namespace per proyek. Jika kelas Anda berada dalam namespace, itu harus berada dalam folder dengan namespace itu ATAU lokasi subfolder yang setidaknya spesifik seperti namespace. Kelas seperti Car.Ford.Fusion (jika Car.Ford adalah ruang nama tunggal Anda) harus berada dalam folder seperti Mobil / Ford ATAU lebih dalam seperti Mobil / Ford / Sedan, sedemikian rupa sehingga folder tersebut setidaknya sama spesifiknya dengan namespace. Hanya saja, jangan memasukkannya ke dalam Mobil / Tidak Terkait / Ford; itu membingungkan.
Triynko

25

@ classevk: Saya setuju dengan aturan ini, dan punya satu lagi untuk ditambahkan.

Ketika saya memiliki kelas bersarang, saya masih membaginya, satu per file. Seperti ini:

// ----- Foo.cs
partial class Foo
{
    // Foo implementation here
}

dan

// ----- Foo.Bar.cs
partial class Foo
{
    class Bar
    {
        // Foo.Bar implementation here
    }
}

5

Saya akan mengatakan ya.

Pertama, akan lebih mudah untuk menemukan file kode aktual dengan mengikuti ruang nama (misalnya, ketika seseorang mengirimi Anda tumpukan panggilan pengecualian). Jika Anda membiarkan folder Anda tidak sinkron dengan ruang nama, menemukan file dalam basis kode besar menjadi melelahkan.

Kedua, VS akan menghasilkan kelas baru yang Anda buat di folder dengan namespace yang sama dengan struktur folder induknya. Jika Anda memutuskan untuk berenang melawan ini, itu hanya akan menjadi satu pekerjaan pipa yang harus dilakukan setiap hari ketika menambahkan file baru.

Tentu saja, ini tidak perlu dikatakan bahwa seseorang harus konservatif tentang seberapa dalam hierarki folder / namespace xis berjalan.


4

Ya mereka seharusnya, hanya mengarah pada kebingungan sebaliknya.


2

Apa standarnya?

Tidak ada standar resmi tetapi secara konvensional pola pemetaan folder-ke-namespace paling banyak digunakan.

Di perpustakaan kelas apakah folder biasanya cocok dengan struktur namespace atau apakah itu tas campuran?

Ya, di sebagian besar pustaka kelas folder cocok dengan namespace untuk kemudahan organisasi.

Dengan menggunakan situs kami, Anda mengakui telah membaca dan memahami Kebijakan Cookie dan Kebijakan Privasi kami.
Licensed under cc by-sa 3.0 with attribution required.