Ad alanı ve sınıf adı yönergeleri

Araçlar ve diğer yardım sınıfları söz konusu olduğunda sınıflarımı ve hizmetlerimi doğru adlandırırken sorun yaşıyorum.

Aşağıdakileri nasıl yapılandırırsınız:

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

vb...

Yukarıdaki hizmetle aynı ihtiyaçlara sahip birden fazla hizmetim var. Bir düşünce, tüm bunları uygun bir ad alanına ayırmak ve şöyle görünmesini sağlamaktır:

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

ve bunun gibi. Her ad alanı elbette ayrı bir klasördür. Ancak bu% 100 hissetmez, çünkü muhtemelen DateValidatorsdiğer hizmetlerde daha fazla şey vardır , bu da kolayca istenmeyen bir referansa yol açabilir.

Ayrıca Services.EventService.EventService.csad alanında sınıf adını da içerir, ki bu da iyi değildir. Kullanabilirsiniz Services.Event.EventService.cs, ancak elbette bu ada sahip bir varlık var.

Bu etki alanı modelidir.

Burada ad alanınızı geliştirmek için yapabileceğiniz en büyük şeyin ad alanınızdan kaldırmak Serviceolduğunu düşünüyorum EventService. Ayrıca ad alanlarını daha fazla bu şekilde ayarlayacağım:

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

Yine de bunun bazı iyileştirmeler yapabileceğini düşünüyorum.

İsim alanlarını severdim ama bugünlerde daha azının daha fazla olduğunu düşünüyorum. Ad alanlarınızı derinden iç içe yerleştirmek kodunuzu çok ayrıntılı hale getirebilir ve bir şeyleri çok fazla parçalamak, kalıtım yeteneğinizi azaltır. Örneğin kodunuzda bir DateValidatorsınıf başka bir yerde kolayca kullanılabilir, bu nedenle EventService dışındaki hizmetler artık bir DateValidator sınıfından yararlanabileceğinden, üzerinde çok fazla ad alanı olmamalıdır. Aynısı uzatma yöntemleri için de geçerlidir. Tüm uzantı yöntemlerinizi aynı anda görmeniz gereken (görebildiğim) zaman yok, bu nedenle onu ilgili olanla gruplandırmak daha mantıklı. Bu durumda, EventExtensionsmuhtemelen sizin bağlantınız EventService, bu yüzden mantıklı bir şekilde benim görüşüme göre oturmaları gerekir.

Evrensel bir deseni izlemek için neden Microsoft'tan Genel Adlandırma Yönergeleri ve Ad Alanı Adlandırma Yönergeleri'ni okumuyorsunuz ?

Bence formül <Company>.(<Product>|<Technology>)[.<Feature>][.<Subnamespace>]gayet iyi çalışıyor.

Uygun ad alanı tasarımı hem mantıksal hem de fiziksel tasarımı dikkate alacaktır.

Her ne kadar isim alanları için asıl mantık çoğunlukla nesne ve yöntem adları arasındaki isim çatışmalarını önlemek olsa da, genel çözüm mimarisi ve tasarımında önemli bir unsur haline gelmiştir. Kavramsal hiyerarşinizin ve mantıksal tasarımınızın sadece mantıklı olmasını değil, muhtemelen kodunuzun daha sonra diğer projelere ve ürünlere kolayca paketlenebilen iyi tasarlanmış ve kolayca yeniden kullanılabilir kitaplıklarda paketlenmesini de istersiniz. Belki de daha iyi fiziksel tasarımın istenen sonucu budur.

.NET Framework'e ve ilgili işlevsellik birimlerinin size makul büyüklükte derlemelerde nasıl verildiğine bakın. Bir başvuru ve kullanım deyimi bırakabilirsiniz ve aniden herhangi bir sayıda mutfak lavabosunu sürüklemek zorunda kalmadan ilgili işlevselliğe sahip olabilirsiniz. Bunun nedeni, .NET Framework'ün fiziksel adının (akıllı ad alanı dahil) fiziksel olarak ilgili konuşlandırılabilir birimlerde mantıksal olarak ilgili kodu paketlemesidir. İsim alanları ve montajlar arasında mükemmel bir eşleme oluşturarak, Microsoft'un .NET çerçevesinin mimarları ve geliştiricileri işinizi önemli ölçüde kolaylaştırdı (elbette bazıları başka türlü tartışabilir, ancak yaptıklarıyla oldukça mutluyum).

C # 'da ad alanı gerçekten çok keyfi. Ad alanlarını birbirinden çok uzaktaki montajlara en tuhaf yerlere koyabilirsiniz. Bu alandaki herhangi bir yararlı disiplin gerçekten iyi organize edilmiş bir yazılım ürününe kişisel katkınızdır. Her durumda tam olarak ne yapacağınızı tavsiye etmeye cesaret edemem. Bu cevapta başarmayı umduğum şey, ad alanlarınızı tanımlarken fiziksel tasarımın yanı sıra mantıksal tasarımı da düşünmenizi sağlamaktır. İşleri mantıksal olarak daha alakalı ve konuşlandırılabilir (fiziksel olarak) bir arada tutarsanız, hem sizin hem de bir gün kodunuzla uğraşması gerekebilecek diğerleri için daha kolay şeyler daha sonra olacaktır.

Bu nedenle, ad alanı sorunlarınızı çözerken lütfen kodunuzun montajlarda ve bileşenlerde nasıl paketleneceğini düşünün!