Program kuruluşu

C# uygulaması büyüdükçe kodu düzenlemeniz gerekir. .NET, büyük kod temellerini yönetilebilir tutmak için birlikte çalışan bir kuruluş araçları hiyerarşisi (çözümler, projeler, derlemeler, ad alanları ve türler) sağlar. Burada açıklanan kurallar .NET topluluğunda geniş fikir birliğine yer vermiştir. Belirli nedenlerle sapmanız gerekebilir, ancak bu kuralların ardından kodunuzun tanıdık ve diğer .NET geliştiricileri tarafından gezinilebilir olması sağlanabilir.

Kuruluş hiyerarşisi

Tipik bir .NET uygulamasını en genişten en özele kadar katmanlar halinde düzenleyin:

Her düzey farklı bir amaca hizmet eder. Çözümler geliştirme iş akışınızı düzenler. Projeler birlikte derlenenleri tanımlar ve her proje bir derleme oluşturur. Derlemeler, dağıtım ve sürüm oluşturma birimidir. Ad alanları adlandırma çakışmalarını önler ve türlerin bulunmasını kolaylaştırır. Tek bir derleme birden çok ad alanı içerebilir ve tek bir ad alanı birden çok derlemeye yayılabilir. Türler gerçek davranışı ve verileri tanımlar.

Projeler ve montajlar

Her bir proje tek bir derleme olarak derlenir: sınıf kitaplığı veya yürütülebilir. Küçük uygulamalar için tek bir projeyle başlayın; erken ayrılmayın. Ayrı bir proje oluşturmanın birincil nedeni, bu kodu birden fazla uygulamada yeniden kullanmaktır. Yeniden kullanmanın ötesinde, somut bir nedeniniz olduğunda projeleri ekleyin:

• Uygulamalar arasında kod paylaşımı — birden fazla uygulamanın referans aldığı ortak mantığı sınıf kütüphanesine aktarın.
• Ayrı endişeler : Veri erişiminizi, iş mantığınızı ve sunu katmanlarınızı bağımsız tutun.
• Bağımlılıkları denetleme — bir proje yalnızca açıkça başvurabileceği projelerdeki türleri kullanabilir.

Tek bir proje birçok uygulama için iyi çalışır. "Her ihtimale karşı" ayrı projeler oluşturma isteğine karşı koy. Daha sonra ikinci bir uygulamanın aynı koda ihtiyacı olduğunda kitaplığı ayıklayabilirsiniz.

Ad alanlarını klasör yapısıyla eşleştirme

Ad alanı adları projenizin klasör yapısına uygun olmalıdır. ad alanını MyApp.Services.Payments gördüğünüzde, bu alandaki türlerin kaynak koduna bakmak için Services/Payments klasörüne bakmalısınız. .NET SDK'sı bu kuralı destekler ve ihlalin diğer geliştiricilerin kafasını o kadar sık karıştırır ki:

// File: Services/OrderService.cs
// Namespace mirrors the folder path
using MyApp.Core;

namespace MyApp.Services;

public class OrderService
{
    public Order CreateOrder(string product, int quantity, decimal price) =>
        new() { ProductName = product, Quantity = quantity, UnitPrice = price };

    public string FormatSummary(Order order) =>
        $"{order.Quantity}x {order.ProductName} = {order.Total:C}";
}

Kök ad alanınız otomatik olarak proje dosyanızın adına ayarlanır. Alt klasörlerdeki türler otomatik olarak alt ad alanlarını almaz; ad alanını her dosyada açıkça bildirmeniz gerekir, ancak bunların her zaman uyum içinde olmasını sağlamalısınız.

<Project Sdk="Microsoft.NET.Sdk">
 <PropertyGroup>
   <RootNamespace>MyCompany.MyApp</RootNamespace>
 </PropertyGroup>
</Project>

Ad alanlarını tür türüne göre değil özelliğe göre düzenleme

İlgili türleri özellik veya sorumluluğa göre ad alanları halinde gruplandırma. Bir arabirimi, uygulamalarını ve destekleyici türleri birlikte yerleştirin:

// Good: group by feature
namespace MyApp.Payments;

public interface IPaymentProcessor
{
    bool ProcessPayment(decimal amount);
}

public class CreditCardProcessor : IPaymentProcessor
{
    public bool ProcessPayment(decimal amount)
    {
        Console.WriteLine($"Processing credit card payment of {amount:C}");
        return true;
    }
}

public record PaymentResult(bool Success, string? TransactionId);

Özellik tabanlı kuruluş, ihtiyacınız olan her şeyi tek bir yerde tutarak kodun daha kolay gezinmesini ve akıl yürütmesini sağlar.

Access değiştiricileri ve derlemeler

Erişim değiştiricileri, erişilebilirliği denetlemek için proje ve derleme yapısıyla çalışır:

• public — bu derlemeye başvuran herhangi bir derlemeden erişilebilir.
• internal — yalnızca aynı derleme içinde erişilebilir (en üst düzey türler için varsayılan değer).
• private, protected, private protected, protected internal — içeren türe, derlemeye veya türetilmiş türlere göre erişilebilir.

internal Diğer projelerin ihtiyaç duymadığı türler için varsayılan olarak. Bu uygulama, uygulama ayrıntılarını gizler ve kullananları etkilemeden yeniden düzenleme özgürlüğü sağlar. Paylaşılan kitaplıklar için özellikle önemlidir:

namespace MyApp.Inventory;

// Public — other projects can use this type
public class InventoryService
{
    public int GetStockLevel(string productName) =>
        StockDatabase.Lookup(productName);
}

// Internal — only visible within this assembly
internal static class StockDatabase
{
    private static readonly Dictionary<string, int> _stock = new()
    {
        ["Widget"] = 42,
        ["Gadget"] = 17
    };

    internal static int Lookup(string productName) =>
        _stock.GetValueOrDefault(productName);
}

Önerilen yöntemler

• Ad alanlarını tutarlı bir şekilde adlandır. Adlandırma deseniniz olarak kullanın CompanyName.ProductName.Feature . Örneğin, kullanın Contoso.Inventory.Shipping. Tutarlı adlandırma, geliştiricilerin arama yapmadan türleri bulmasına yardımcı olur.
• Projelerin odaklanmış kalmasını sağlayın. Her projenin tek ve net bir sorumluluğu olmalıdır. Bir proje çok fazla ilgisiz sorunu işlediğinde, onu bölün.
• Dosya kapsamlı ad alanlarını kullanın. namespace MyApp.Services; sentaksı, girintiyi azaltan ve önerilen stildir. Tüm yeni kodlarda kullanın.
• Varsayılan olarak internal. Türleri yalnızca diğer derlemeler gerçekten ihtiyaç duyduğunda işaretleyin. Erişimi daha sonra istediğiniz zaman genişletebilirsiniz; daraltma, hataya neden olan bir değişikliktir.

İlgili içerik

• Ad alanları ve kullanma yönergeleri
• .NET'te derlemeler
• .NET proje SDK'ları