ASP.NET MVC’de “Areas” ile Büyük Projeleri Yönetmek

Giriş

Büyük ölçekli web projeleri geliştirirken, uygulamanın karmaşıklığı zamanla artar ve tüm denetleyicilerin (controllers) tek bir klasör altında toplanması yönetilemez bir hal alabilir. Bu durum, özellikle farklı işlevselliklere sahip modüllerin veya kullanıcı arayüzlerinin bir arada bulunduğu projelerde, kod tekrarı, dosya bulma zorluğu ve genel proje organizasyonu açısından ciddi sorunlar yaratır. ASP.NET Core MVC framework’ü, bu tür mimari zorlukları aşmak için “Areas” (Alanlar) kavramını sunar. Areas, uygulamanın farklı bölümlerini mantıksal olarak ayırarak, her bir bölümün kendi denetleyici, görünüm ve model klasör yapısına sahip olmasını sağlar. Bu yaklaşım, projenin okunabilirliğini, bakımını ve ölçeklenebilirliğini önemli ölçüde artırır. Bu yazıda, özellikle bir Yönetim Paneli (Admin) ve Ön Yüz (UI) olmak üzere, Areas yapısının nasıl oluşturulacağını ve kullanıldığını detaylıca inceleyeceğiz.

Areas nedir ve neden kullanılır?

ASP.NET Core MVC’deki Areas, uygulamanızın farklı bölümlerini bağımsız birer MVC uygulaması gibi organize etmenizi sağlayan bir yapıdır. Her bir Area, kendine ait bir Controllers, Views ve Models klasörüne sahip olabilir. Bu, projenin ana Controllers, Views ve Models klasörlerini daha genel tutarken, belirli bir modül veya işlevsellik için özel yapılandırmaları ve bileşenleri izole etmenizi sağlar.

Areas kullanmanın temel nedenleri şunlardır:

• Modülerlik: Uygulamayı mantıksal olarak ayrı, yönetilebilir modüllere böler. Örneğin, bir e-ticaret uygulamasında “Admin”, “Müşteri” ve “Ürün” gibi ayrı Alanlar oluşturulabilir.
• Organizasyon: Büyük projelerde, yüzlerce denetleyici ve görünüm dosyasını tek bir klasörde tutmak yerine, ilgili dosyaları kendi Alanları altında gruplayarak dosya yapısını düzenler.
• Adlandırma Çakışmalarını Önleme: Farklı Alanlarda aynı ada sahip denetleyiciler veya görünümler olabilir (örneğin, hem Admin hem de UI alanında bir “Home” denetleyicisi). Areas, bu adlandırma çakışmalarını routing mekanizması aracılığıyla kolayca yönetir.
• Bakım ve Ölçeklenebilirlik: Bir Alan üzerinde çalışırken, diğer Alanlardaki kodların karmaşıklığıyla uğraşmak zorunda kalmazsınız. Bu, özellikle büyük ekiplerde farklı modüller üzerinde paralel çalışmayı kolaylaştırır ve projenin uzun vadeli bakımını basitleştirir.

Yönetim paneli (admin) ve ön yüz (ui) için alan (area) oluşturma

Bir ASP.NET Core projesinde Yönetim Paneli ve Ön Yüz için ayrı Alanlar oluşturmak, projenin yapısını net bir şekilde bölmek için mükemmel bir yöntemdir. Bu ayrımı yapmak için aşağıdaki adımlar izlenir ve yapılandırma yapılır:

1. Areas klasörünü oluşturma: Projenizin kök dizininde (örneğin, YourProjectName) Areas adında yeni bir klasör oluşturun.
2. Alan klasörlerini oluşturma: Areas klasörünün içine, her bir Alan için ayrı bir klasör oluşturun. Örneğin, Admin ve UI adında iki klasör oluşturun.
3. Her Alan için MVC yapısı: Her bir Alan klasörünün (örneğin, Admin ve UI) içine standart bir MVC projesindeki gibi Controllers, Views ve isteğe bağlı olarak Models klasörlerini ekleyin.
4. Denetleyicileri Alanlara atama: Bir denetleyiciyi belirli bir Alan’a atamak için, denetleyici sınıfının üzerine [Area("AreaName")] niteliğini (attribute) eklemeniz gerekir.

   Örneğin, Admin alanı için bir denetleyici:

   
   using Microsoft.AspNetCore.Mvc;
   
   namespace YourProject.Areas.Admin.Controllers
   {
       [Area("Admin")]
       public class DashboardController : Controller
       {
           public IActionResult Index()
           {
               return View();
           }
       }
   }
           

   UI alanı için bir denetleyici:

   
   using Microsoft.AspNetCore.Mvc;
   
   namespace YourProject.Areas.UI.Controllers
   {
       [Area("UI")]
       public class HomeController : Controller
       {
           public IActionResult Index()
           {
               return View();
           }
       }
   }
           

5. Alan routing’ini yapılandırma: Startup.cs dosyasında veya .NET 6+ projelerinde Program.cs dosyasında Alanlar için özel route (yönlendirme) tanımlamanız gerekir. Bu genellikle MapControllerRoute metodunun bir aşırı yüklemesi ile yapılır. Alan route’larını varsayılan route’lardan önce tanımlamak önemlidir.

   Örneğin, Program.cs içinde:

   
   app.MapControllerRoute(
       name: "admin",
       pattern: "{area:exists}/{controller=Dashboard}/{action=Index}/{id?}");
   
   app.MapControllerRoute(
       name: "default",
       pattern: "{controller=Home}/{action=Index}/{id?}");
           

   Burada, {area:exists} route parametresi, isteğin bir Alan’a ait olup olmadığını kontrol eder. Eğer URL’de bir Area adı varsa (örneğin, /Admin/Dashboard), istek bu route kuralına göre işlenir. Varsayılan UI Alanınız için ise genellikle ayrı bir “UI” ön eki kullanmayıp doğrudan /{controller}/{action} şeklinde yönlendirme yaparsınız. Eğer UI alanını da açıkça belirtmek isterseniz, ikinci bir Alan route’u tanımlayabilirsiniz: app.MapControllerRoute(name: "ui", pattern: "UI/{controller=Home}/{action=Index}/{id?}");

Areas’larda klasör yapısı ve çalışma prensibi

Areas’ların klasör yapısı, uygulamanın genel yapısını taklit eder ancak her bir Alan için kapsüllenmiş bir formdadır. İşte tipik bir Admin ve UI Alan yapısı örneği:

YourProjectRoot/
├── Areas/
│   ├── Admin/
│   │   ├── Controllers/
│   │   │   ├── DashboardController.cs
│   │   │   ├── ProductController.cs
│   │   ├── Views/
│   │   │   ├── Dashboard/
│   │   │   │   ├── Index.cshtml
│   │   │   ├── Product/
│   │   │   │   ├── List.cshtml
│   │   │   │   ├── Create.cshtml
│   │   │   ├── Shared/
│   │   │   │   ├── _AdminLayout.cshtml  // Admin'e özel layout
│   │   │   │   ├── _ViewImports.cshtml
│   │   │   │   ├── _ViewStart.cshtml
│   │   ├── Models/
│   │   │   ├── AdminProductViewModel.cs
│   │   │   ├── UserManagementViewModel.cs
│   ├── UI/
│   │   ├── Controllers/
│   │   │   ├── HomeController.cs
│   │   │   ├── ShopController.cs
│   │   │   ├── AccountController.cs
│   │   ├── Views/
│   │   │   ├── Home/
│   │   │   │   ├── Index.cshtml
│   │   │   │   ├── Privacy.cshtml
│   │   │   ├── Shop/
│   │   │   │   ├── ProductDetail.cshtml
│   │   │   ├── Account/
│   │   │   │   ├── Login.cshtml
│   │   │   │   ├── Register.cshtml
│   │   │   ├── Shared/
│   │   │   │   ├── _Layout.cshtml  // UI'a özel layout
│   │   │   │   ├── _ViewImports.cshtml
│   │   │   │   ├── _ViewStart.cshtml
│   │   ├── Models/
│   │   │   ├── ProductListingViewModel.cs
│   │   │   ├── UserLoginViewModel.cs
├── Controllers/  // Uygulamanın ana/global denetleyicileri (varsa)
│   ├── ErrorController.cs
├── Views/  // Uygulamanın ana/global görünümleri (varsa)
│   ├── Shared/
│   │   ├── _Layout.cshtml  // Yedek/genel layout
│   ├── _ViewImports.cshtml
│   ├── _ViewStart.cshtml
├── wwwroot/
├── Program.cs
├── appsettings.json

Çalışma Prensibi:

• Routing: Bir istek geldiğinde, ASP.NET Core önce Alan route’larını ("{area:exists}/...") kontrol eder. Eğer URL bir Alan adı içeriyorsa (örneğin, /Admin/Dashboard/Index), ilgili Alanın denetleyicisi aranır. Eğer bir Alan eşleşmezse, global route’lar ("{controller}/{action}") devreye girer.
• View Resolution: Bir denetleyici bir görünüm döndürdüğünde (örneğin, return View();), görünüm arama sırası şöyledir:
  1. Önce, o anki Alanın içindeki ilgili denetleyicinin görünüm klasörü aranır (örneğin, /Areas/Admin/Views/Dashboard/Index.cshtml).
  2. Daha sonra, o anki Alanın içindeki Shared klasörü aranır (örneğin, /Areas/Admin/Views/Shared/Index.cshtml).
  3. Son olarak, uygulamanın ana Views klasörü ve Views/Shared klasörü aranır (örneğin, /Views/Shared/Index.cshtml). Bu sayede, Alanlara özgü görünümler öncelikli olurken, genel görünümler yedek olarak kullanılabilir.
• Layouts: Her Alanın kendi _ViewStart.cshtml dosyasında kendi özel layout dosyasını (örneğin, _AdminLayout.cshtml) belirtme esnekliği vardır. Bu, Yönetim Paneli ve Ön Yüz için tamamen farklı kullanıcı arayüzü tasarımları oluşturulmasına olanak tanır.

Sonuç

ASP.NET Core’daki Areas yapısı, özellikle büyük ve karmaşık projelerde uygulamanın mimarisini düzenlemek ve sürdürülebilirliğini artırmak için hayati bir araçtır. Yönetim Paneli (Admin) ve Ön Yüz (UI) gibi farklı işlevselliklere sahip bölümlerin ayrı Alanlar olarak yapılandırılması, kodun modülerliğini, okunabilirliğini ve bakım kolaylığını önemli ölçüde artırır. Her bir Alanın kendi MVC klasör yapısına sahip olması, geliştiricilerin belirli bir işlevsellik üzerinde çalışırken diğer bölümlerin karmaşıklığından izole olmalarını sağlar. Bu, proje ölçeklendikçe dosya karmaşasını azaltır, adlandırma çakışmalarını önler ve farklı geliştirme ekiplerinin paralel çalışmasına olanak tanır. Sonuç olarak, Areas yapısını doğru bir şekilde uygulamak, uzun vadede daha sağlam, yönetilebilir ve esnek web uygulamaları geliştirmenize olanak tanır, böylece projenin büyümesiyle ortaya çıkabilecek potansiyel sorunların önüne geçilir.