Hayır.
Hem single (ben) hem de bir geliştirici ekibi ile küçük ve büyük projelerde her iki yöntemi de denedim.
En basit ve en verimli yolun proje başına tek bir ad alanına sahip olmak olduğunu ve tüm sınıfların bu ad alanına gittiğini buldum. Ardından, sınıf dosyalarını istediğiniz proje klasörlerine koymakta özgürsünüz. Yalnızca tek bir ad alanı olduğundan, her zaman dosyaların üstüne using ifadeleri eklemekle ilgili bir karışıklık yoktur.
Kaynak dosyaları klasörler halinde düzenlemek önemlidir ve bence tüm klasörler bunun için kullanılmalıdır. Bu klasörlerin ad alanlarıyla da eşleşmesini şart koşmak gereksizdir, daha fazla çalışma yaratır ve eklenen yük düzensizliği teşvik ettiği için aslında organizasyon için zararlı olduğunu fark ettim.
Örneğin bu FxCop uyarısını alın:
CA1020: Birkaç türe sahip ad alanlarından kaçının
nedeni: Genel ad alanı dışındaki bir ad alanı beşten az tür içerir
https://msdn.microsoft.com/en-gb/library/ms182130.aspx
Bu uyarı, yeni bir klasör oluşturmayı gerekçelendirmek için dört benzer sınıfınız olana kadar yeni dosyaların genel bir Project.General klasörüne veya hatta proje köküne atılmasını teşvik eder. Bu hiç olacak mı?
Dosyaları Bulmak
Kabul edilen yanıt, "Sınıfların bulunması daha kolay olacak ve bu tek başına yeterince iyi nedenler olmalı" diyor.
Cevabın, önerdiğim şeyden ziyade, tek bir ad alanına sahip bir proje olduğunu önerdiğimden ziyade, bir projede klasör yapısıyla eşleşmeyen birden çok ad alanına atıfta bulunduğundan şüpheleniyorum.
Her durumda, ad alanından bir sınıf dosyasının hangi klasörde olduğunu belirleyemezken, Visual Studio'daki Tanıma Git veya arama çözümü gezgini kutusunu kullanarak onu bulabilirsiniz. Ayrıca bence bu gerçekten büyük bir sorun değil. Geliştirme zamanımın% 0,1'ini bile optimize etmeyi haklı çıkarmak için dosya bulma sorununa harcamıyorum.
İsim çatışmaları
Elbette birden çok ad alanı oluşturmak, projenin aynı ada sahip iki sınıfa sahip olmasına izin verir. Ama bu gerçekten iyi bir şey mi? Bunun mümkün olmasına izin vermemek belki daha mı kolay? Aynı ada sahip iki sınıfa izin vermek, işlerin% 90'ının belirli bir şekilde çalıştığı ve sonra aniden özel bir durumunuzun olduğunu fark ettiğiniz daha karmaşık bir durum yaratır. Ayrı ad alanlarında tanımlanmış iki Rectangle sınıfınız olduğunu varsayalım:
- sınıf Project1.Image.Rectangle
- sınıf Project1.Window.Rectangle
Bir kaynak dosyanın her iki ad alanını da içermesi gerektiği bir soruna ulaşmak mümkündür. Şimdi bu dosyanın her yerine tam ad alanını yazmanız gerekiyor:
var rectangle = new Project1.Window.Rectangle();
Veya bazı kötü kullanım ifadeleriyle uğraşın:
using Rectangle = Project1.Window.Rectangle;
Projenizde tek bir isim alanıyla farklı bir isim bulmak zorunda kalıyorsunuz ve daha açıklayıcı isimler şu şekilde:
- sınıf Project1.ImageRectangle
- sınıf Project1.WindowRectangle
Ve kullanım her yerde aynıdır, bir dosya her iki türü de kullandığında özel bir durumla uğraşmanıza gerek yoktur.
ifadeleri kullanma
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;
Kod yazarken her zaman ad alanı eklemek zorunda kalmama kolaylığı. Gerçekten gereken zaman değil, bunu yapmak zorunda kalmanın ve sadece dosyaları çok sayıda kullanım ifadeleriyle doldurmanın akışındaki kesinti - ne için? Buna değer mi?
Proje klasör yapısını değiştirme
Klasörler ad alanlarına eşlenirse, proje klasörü yolu her kaynak dosyaya etkili bir şekilde sabit kodlanır. Bu, projedeki herhangi bir dosya veya klasörün yeniden adlandırılması veya taşınması için gerçek dosya içeriğinin değiştirilmesi gerektiği anlamına gelir. Hem o klasördeki dosyaların ad alanı bildirimi hem de o klasördeki sınıflara başvuran diğer bir grup dosyadaki ifadelerin kullanılması. Değişikliklerin kendileri araçlarla önemsiz olsa da, genellikle sınıfları bile değişmemiş birçok dosyadan oluşan büyük bir kaydetme ile sonuçlanır.
Projede tek bir ad alanıyla, proje klasör yapısını, herhangi bir kaynak dosyanın kendisi değiştirilmeden istediğiniz gibi değiştirebilirsiniz.
Visual Studio, yeni bir dosyanın ad alanını, oluşturulduğu proje klasörüne otomatik olarak eşler
Ne yazık ki, ad alanını düzeltme zahmetinin onlarla uğraşmaktan daha az olduğunu düşünüyorum. Ayrıca Add-> New kullanmak yerine mevcut bir dosyayı kopyalayıp yapıştırma alışkanlığı edindim.
Intellisense ve Nesne Tarayıcısı
Büyük projelerde birden çok ad alanı kullanmanın en büyük yararı, sınıfları bir ad alanı hiyerarşisinde görüntüleyen herhangi bir araçta sınıfları görüntülerken fazladan organizasyona sahip olmaktır. Hatta dokümantasyon. Açıkçası, projede yalnızca bir ad alanına sahip olmak, tüm sınıfların kategorilere ayrılmak yerine tek bir listede görüntülenmesiyle sonuçlanır. Bununla birlikte, kişisel olarak, bunun eksikliğinden dolayı asla şaşırmadım veya gecikmedim, bu yüzden birden fazla ad alanını haklı çıkarmak için yeterince büyük bir fayda görmüyorum.
Büyük bir halka açık sınıf kitaplığı yazıyor olsaydım , muhtemelen projede birden çok ad alanı kullanırdım, böylece montaj takım ve belgelerde düzgün görünüyordu.