Bir sınıf veya modül ne zaman ayrı bir Derleme / DLL olmalıdır?

Bir sınıfın ne zaman kendi meclisinde / DLL'sinde olması gerektiğine karar vermek için kurallar var mı? Sık sık iki düşünce okulu görüyorum:

1) Sınıfların her "gruplaması" kendi DLL'sine aittir.

2) Her şey tek bir DLL dosyasında olmalıdır ancak ad alanları / klasörler yoluyla ayrılmalıdır; örneğin, Core.Repositories, Core.Services, Core.DTO, vb.

İşyerinde her şeyi "İş" olarak adlandırılan tek bir Meclis'te topladık. Bazı klasörler var ancak gerçek bir ayrılık yok - iş nesneleri (bazıları sınıf olmamalı mantık içeren) "BusinessObjects" klasöründe dikkatsizce toplanıyor. Birden fazla sınıfta kullanılan şeyler "Çekirdek" klasöründedir. Yardımcı programlar "Yardımcı Programlar" klasöründedir, veri erişim altyapısı "Veri" klasöründedir - anladınız.

Üzerinde çalışmakta olduğum yeni bir modül için ayrı bir veri erişim katmanına sahip olmak istiyorum / ihtiyacım var (temel bir Depo uygulaması düşünüyorum) ancak diğer 160'ın (!) "BusinessObjects" klasörü altına atmak istemiyorum. orada sınıflar. Aynı zamanda yeni bir Sınıf Kütüphanesi oluşturmaktan endişe duyuyorum çünkü herkes tek bir Kütüphanede bir sınıfı doldurmaya alışkın; ancak bir klasör / ad alanı işe yarayabilir.

c# architecture directory-structure

— Wayne Molina
kaynak

Yanıtlar:

Her projede kategorilere ayrılan sınıflarla daha fazla projeye (yani montajlara) sahip olmak, bu sınıfların hepsinde ayrı ad alanlarında ayrı bir projeden daha iyi olduğunu düşünüyorum. Projelerinizin yeniden kullanılabilir olmasını hedeflemeli ve bir uygulamada farklı katmanları temsil etmelisiniz. Ardından, bu projeleri bir sürü gereksiz sınıfa dahil etmek zorunda kalmadan gelecekteki uygulamalarda kolayca yeniden kullanabilirsiniz.

Mesela, söylediklerinize dayanarak, kesinlikle aşağıdaki projeleri yapacağım:

çekirdek
Veri
Etki alanı (veya BusinessObjects)
Hizmetler
Yardımcı programlar (veya Yardımcılar)

— Bernard
kaynak

Maalesef cevabı aşağı oylayamam. Bu tam olarak firmamızda tavsiye edilen şeydir. Sonuç olarak, 6 ya da daha fazla projeye sahip olmak gibi, örneğin orta büyüklükteki bir web sitesi için, özellik tabanlı dizin hiyerarşisini koruyamazsınız. Sonuç olarak, her biriyle birlikte altı projeyle sonuçlanacaksa, dosya yığınlarında gezinmek imkansız hale gelir. Genellikle bunu tavsiye eden insanlar, projelerin özellik tabanlı yapısını nispeten büyük projelerde hiç denememişlerdir (doğrudan karar verdiğim için üzgünüm ama bu tür aşırı doldurma sonuçlarının üstesinden gelmek gerçek bir acıdır). Jammycakes cevap doğru yaklaşım önerir.

— alehro

Sınıfları kategorilere ayırmak, büyük projelerde karışıklığa yol açan şeydir. Bunları özelliğe / boyuta göre bölün. Sonra ad alanları sadece bu bölümü yansıtıyor olacak. Ve tüm yapı sözlüğü belirtimden yansıtacaktır. Sınıfları kategorilere ayırmak değişken isimlerine tip kısaltmaları eklemek gibidir - genellikle kötü koku.

— alehro

Her iki önerilen çözümü kötüye kullanmak kolaydır (yani, çok fazla proje veya çok az). Yeniden kullanılabilirliğin ve düşük eşleşmenin akılda tutulduğu iyi bir denge bulmak, daha test edilebilir ve sürdürülebilir bir şeye yol açmalıdır.

— Bernard,

"Bob Amca" Temiz Kod Martin, SOLID Prensipleri şöhreti burada üç prensip ortaya koymuştur :

Serbest Bırakma Yeniden Eşdeğerliği Prensibi: Yeniden kullanım granülü, serbest bırakma granülüdür.
Ortak Kapanış İlkesi: Birlikte değişen sınıflar birlikte paketlenir.
Ortak Yeniden Kullanım Prensibi: Birlikte kullanılan sınıflar birlikte paketlenir.

Genel kural, çözümünüzdeki proje sayısını mümkün olduğunca düşük tutmanız gerektiğidir. Bir veya daha fazla belirli kullanıcı öyküsü uygulamak için bunu yapmanız gerekiyorsa veya tek bir montajın ölçülebilir performans sorunlarına neden olması durumunda (genellikle birkaç megabayt boyutunda olduklarında) bölün.

— jammycakes
kaynak

+1 bu ilkeler iyi kurallardır. Sınıfları farklı düzeneklere ayırmak, genel kod tabanını artırarak bakım maliyetini artırarak (örneğin her bir düzeneğin hangi sürümlerinin birlikte çalışmasına izin verildiğini) ek tasarım hususları sunar.

— Ben

Ancak, bu ilkelere ek olarak, ayrı bir montajda değiştirilmesi veya değiştirilmesi muhtemel olan kodu paketlemenin genellikle iyi bir fikir olduğunu ekleyeceğim. Bu kod, ayrı montajların birleştirilmesi için gerekli olan ilave hususlardan faydalanacak ve ayrı olması, farklı versiyonların test edilmesini ve karşılaştırılmasını kolaylaştıracaktır.

— Ben

Evet, ancak değiştirilmesi veya değiştirilmesi için gerçek bir gereklilik olduğundan emin olun. Örneğin, çerçeveler ve üçüncü taraf kütüphaneleri - NuGet paketleri ve benzerleri - genellikle birden fazla IOC kabını ve birden fazla günlük çerçevesini desteklemesi gerekir. Öte yandan, kullanıcı kodu için bu tür soyutlamalar genellikle tamamen spekülatif, gereksiz ve engelleyicidir ve en sonunda ihtiyaç duyulduğunda nadir durumlarda asla bitmez.

— jammycakes

"Bir veya daha fazla belirli kullanıcı hikayesi uygulamak için yapmanız gerekiyorsa veya tek bir montajın ölçülebilir performans sorunlarına neden oluyorsa (genellikle birkaç megabayt boyutunda olduklarında) onları ayırın." - tamamen rastgele ve gerçeklik tavsiyesine dayandırılmadı

— hyankov 17:17

Üzgünüm, ama tam olarak "tamamen rastlantısal ve gerçekliğe dayandırılmayan" konuyla ilgili nedir? Bu cevabı, yıllar itibariyle, gerekenden çok daha fazla projeye bölünmüş çözümler üzerinde çalıştıktan sonra ne yapmanız gerektiğinden başka bir sebep olmadan yayınladım. Sonuç? Buzul derleme zamanları ve bol miktarda bağımlılık cehennemi (özellikle NuGet öncesi günlerde). Eşyaları ayrı toplanmalara bölmenin bir maliyeti vardır ve bu maliyeti telafi etmenin bir yararı yoksa, o zaman bu sadece işyerinden çalma durumudur.

— jammycakes

Çalıştığım diğer bazı rehber ilkeler:

Bu kodu başka projelerde tekrar kullanacağınızı düşünüyor musunuz? İlgili web uygulamalarından oluşan bir grup için, tüm uygulamaların kullandığı, kullanıcı hesapları ve girişler için aynı modeli kullandığından, kullanıcı hesaplarıyla ilgili bir modülümüz vardı. Geometri ve matematik kütüphaneleri ile benzer şeyler yaptım ve onları sadece DLL dahil olmak üzere çoklu uygulamalarda kullandım.
Tüm projeyi yeniden dağıtmadan / yeniden derlemeden bu kodu değiştirebilmek / dağıtabilmek ister misiniz? Bazen sadece modülü yeniden kurmak, dağıtmak ve web uygulamasını yeniden başlatmak faydalı oldu.

Sizin durumunuzda basit ve genel bir Havuz gelecekte daha yararlı olabilir, eğer mümkünse onu yeni bir DLL dosyasına ayırmak faydalı olabilir.

— FrustratedWithFormsDesigner
kaynak

Sanırım ikinci noktan gerçekten mantıklı. Modüllere bölünmesi geliştirme / test etme ve derleme sürelerine yardımcı olmalıdır.

— WM