در این مقاله، به بررسی جامع پیاده‌سازی معماری لایه‌ای در ASP.NET Core MVC می‌پردازیم. از مفاهیم اولیه و مزایای این معماری شروع کرده و با گذر از لایه‌های مختلف، نحوه پیاده‌سازی عملی آن‌ها را با استفاده از الگوهای طراحی رایج مانند Repository و Unit of Work تشریح خواهیم کرد.

معماری لایه‌ای چیست و چرا اهمیت دارد؟

معماری لایه‌ای، رویکردی برای طراحی نرم‌افزار است که در آن، اجزای مختلف برنامه بر اساس وظایفشان در لایه‌های افقی مجزا سازماندهی می‌شوند. هر لایه، مجموعه‌ای از مسئولیت‌های مشخص را بر عهده دارد و تنها با لایه‌های مجاور خود در ارتباط است. این جداسازی مسئولیت‌ها (Separation of Concerns)، یکی از اصول بنیادین مهندسی نرم‌افزار است که به تولید کدهای تمیزتر، قابل فهم‌تر و با قابلیت نگهداری بالاتر منجر می‌شود.

یک معماری لایه‌ای معمولاً شامل سه لایه اصلی است:

• لایه ارائه (Presentation Layer): این لایه که با نام لایه رابط کاربری (UI) نیز شناخته می‌شود، مسئولیت تعامل با کاربر و نمایش اطلاعات را بر عهده دارد. در یک اپلیکیشن ASP.NET Core MVC، این لایه شامل Controllerها، Viewها و ViewModelها می‌شود.

• لایه منطق کسب‌وکار (Business Logic Layer - BLL): این لایه، قلب تپنده اپلیکیشن است و قوانین و منطق اصلی کسب‌وکار در آن پیاده‌سازی می‌شود. این لایه مستقل از نحوه نمایش اطلاعات و نحوه ذخیره‌سازی آن‌ها عمل می‌کند.

• لایه دسترسی به داده (Data Access Layer - DAL): این لایه مسئولیت ارتباط با پایگاه داده و انجام عملیات CRUD (Create, Read, Update, Delete) را بر عهده دارد. استفاده از این لایه، منطق کسب‌وکار را از جزئیات فنی نحوه ذخیره‌سازی داده‌ها جدا می‌کند.

مزایای استفاده از معماری لایه‌ای

استفاده از این معماری مزایای قابل توجهی را به همراه دارد:

• قابلیت نگهداری (Maintainability): با جدا کردن بخش‌های مختلف برنامه، اعمال تغییرات در یک لایه، تأثیر کمتری بر سایر لایه‌ها خواهد داشت. این امر، فرآیند توسعه و رفع خطا را ساده‌تر می‌کند.

• قابلیت استفاده مجدد (Reusability): منطق کسب‌وکار و کدهای دسترسی به داده می‌توانند در پروژه‌های مختلف مجدداً مورد استفاده قرار گیرند.

• تست‌پذیری (Testability): هر لایه را می‌توان به صورت مستقل از سایر لایه‌ها تست کرد. این ویژگی، نوشتن تست‌های واحد (Unit Tests) را آسان‌تر کرده و کیفیت نهایی نرم‌افزار را افزایش می‌دهد.

• توسعه‌پذیری (Scalability): می‌توان هر لایه را به صورت مستقل مقیاس‌پذیر کرد. برای مثال، در صورت افزایش بار روی پایگاه داده، می‌توان تنها لایه دسترسی به داده را تقویت کرد.

• توسعه موازی: تیم‌های مختلف می‌توانند به صورت همزمان روی لایه‌های متفاوت کار کنند که این امر سرعت توسعه را افزایش می‌دهد.

ساختار پروژه در ASP.NET Core MVC

برای پیاده‌سازی معماری لایه‌ای، بهتر است ساختار پروژه را به گونه‌ای سازماندهی کنیم که هر لایه در یک پروژه مجزا قرار گیرد. یک ساختار پیشنهادی می‌تواند به شکل زیر باشد:

• Solution

  • ProjectName.Web (ASP.NET Core MVC Project): این پروژه، لایه ارائه ما خواهد بود و شامل Controllerها، Viewها، ViewModelها و فایل‌های استاتیک است. این پروژه به لایه Business Logic ارجاع خواهد داشت.

  • ProjectName.Business (Class Library): این پروژه، لایه منطق کسب‌وکار را در خود جای می‌دهد. سرویس‌ها و منطق اصلی برنامه در این لایه قرار می‌گیرند. این پروژه به لایه Data Access ارجاع خواهد داشت.

  • ProjectName.Data (Class Library): این پروژه، لایه دسترسی به داده است و شامل Context پایگاه داده، Repositoryها و مدل‌های دامنه (Entities) می‌شود.

  • ProjectName.Domain (Class Library): گاهی اوقات یک لایه مجزا برای مدل‌های دامنه (Entities) و اینترفیس‌های Repositoryها در نظر گرفته می‌شود تا وابستگی‌ها معکوس شده و لایه‌های بالاتر به جزئیات پیاده‌سازی لایه داده وابسته نباشند.

این ساختار، جداسازی منطقی و فیزیکی لایه‌ها را تضمین می‌کند و به مدیریت بهتر وابستگی‌ها کمک می‌کند.

پیاده‌سازی لایه دسترسی به داده (DAL)

این لایه وظیفه تعامل با پایگاه داده را بر عهده دارد. برای پیاده‌سازی این لایه، از Entity Framework Core به عنوان ORM (Object-Relational Mapper) و الگوهای طراحی Repository و Unit of Work استفاده می‌کنیم.

الگوی Repository

الگوی Repository یک لایه انتزاعی بین لایه منطق کسب‌وکار و لایه دسترسی به داده ایجاد می‌کند. این الگو، کوئری‌های مربوط به دسترسی به داده را در یک مکان متمرکز کرده و از تکرار کد جلوگیری می‌کند.

برای پیاده‌سازی این الگو، ابتدا یک اینترفیس عمومی (Generic Interface) برای Repository تعریف می‌کنیم:

public interface IRepository where T : class
{
    Task> GetAllAsync();
    Task GetByIdAsync(int id);
    Task AddAsync(T entity);
    void Update(T entity);
    void Delete(T entity);
}

سپس، یک کلاس عمومی برای پیاده‌سازی این اینترفیس ایجاد می‌کنیم:

public class Repository : IRepository where T : class
{
    protected readonly ApplicationDbContext _context;

    public Repository(ApplicationDbContext context)
    {
        _context = context;
    }

    // پیاده‌سازی متدها
}

الگوی Unit of Work

الگوی Unit of Work لیستی از عملیات‌هایی که باید در یک تراکنش (Transaction) انجام شوند را نگهداری می‌کند. این الگو تضمین می‌کند که تمام تغییرات به صورت یکجا در پایگاه داده ذخیره شوند یا در صورت بروز خطا، هیچ‌کدام از آن‌ها اعمال نشوند (Rollback). EF Core به صورت داخلی از این الگو پشتیبانی می‌کند و کلاس DbContext نقش Unit of Work را ایفا می‌کند. با این حال، ایجاد یک کلاس مجزا برای Unit of Work به ما کمک می‌کند تا تمام Repositoryها را در یکجا مدیریت کرده و متد SaveChanges را به صورت متمرکز فراخوانی کنیم.

اینترفیس Unit of Work:

public interface IUnitOfWork : IDisposable
{
    IProductRepository Products { get; }
    // سایر Repositoryها
    Task CompleteAsync();
}

کلاس پیاده‌سازی Unit of Work:

public class UnitOfWork : IUnitOfWork
{
    private readonly ApplicationDbContext _context;
    public IProductRepository Products { get; private set; }

    public UnitOfWork(ApplicationDbContext context)
    {
        _context = context;
        Products = new ProductRepository(_context);
    }

    public async Task CompleteAsync()
    {
        return await _context.SaveChangesAsync();
    }

    public void Dispose()
    {
        _context.Dispose();
    }
}

پیاده‌سازی لایه منطق کسب‌وکار (BLL)

این لایه، واسطی بین لایه ارائه و لایه دسترسی به داده است. منطق و قوانین اصلی برنامه در این لایه و در قالب سرویس‌ها (Services) پیاده‌سازی می‌شوند. سرویس‌ها از طریق Unit of Work با لایه داده در ارتباط هستند.

برای مثال، یک سرویس برای مدیریت محصولات می‌تواند به شکل زیر باشد:

public interface IProductService
{
    Task> GetAllProductsAsync();
    Task CreateProductAsync(Product product);
    // سایر متدها
}

public class ProductService : IProductService
{
    private readonly IUnitOfWork _unitOfWork;

    public ProductService(IUnitOfWork unitOfWork)
    {
        _unitOfWork = unitOfWork;
    }

    public async Task> GetAllProductsAsync()
    {
        return await _unitOfWork.Products.GetAllAsync();
    }

    public async Task CreateProductAsync(Product product)
    {
        // اعمال قوانین کسب‌وکار
        // برای مثال، بررسی عدم تکراری بودن نام محصول
        await _unitOfWork.Products.AddAsync(product);
        await _unitOfWork.CompleteAsync();
    }
}

پیاده‌سازی لایه ارائه (Presentation Layer)

این لایه، نقطه ورود کاربر به اپلیکیشن است. در ASP.NET Core MVC، Controllerها مسئول دریافت درخواست‌های HTTP، فراخوانی سرویس‌های مناسب از لایه منطق کسب‌وکار و ارسال نتایج به Viewها برای نمایش به کاربر هستند.

تزریق وابستگی (Dependency Injection)

ASP.NET Core به صورت داخلی از الگوی تزریق وابستگی (Dependency Injection - DI) پشتیبانی می‌کند. این ویژگی به ما اجازه می‌دهد تا وابستگی‌های بین لایه‌ها را به صورت سست (Loosely Coupled) مدیریت کنیم. به جای اینکه یک کلاس، نمونه‌ای از کلاس‌های دیگر را مستقیماً ایجاد کند، این وابستگی‌ها از طریق سازنده (Constructor) به آن تزریق می‌شوند.

ابتدا باید سرویس‌ها و Unit of Work را در فایل Program.cs (یا Startup.cs در نسخه‌های قدیمی‌تر) به DI Container معرفی کنیم:

builder.Services.AddScoped();
builder.Services.AddScoped();

سپس می‌توانیم سرویس مورد نظر را به Controller تزریق کنیم:

public class ProductsController : Controller
{
    private readonly IProductService _productService;

    public ProductsController(IProductService productService)
    {
        _productService = productService;
    }

    public async Task Index()
    {
        var products = await _productService.GetAllProductsAsync();
        return View(products);
    }

    // سایر Actionها
}

همانطور که مشاهده می‌شود، Controller هیچ اطلاعی از نحوه پیاده‌سازی لایه داده یا منطق کسب‌وکار ندارد و تنها با اینترفیس IProductService در ارتباط است. این جداسازی، تست‌پذیری و انعطاف‌پذیری کد را به شدت افزایش می‌دهد.

نتیجه‌گیری

معماری لایه‌ای یک الگوی قدرتمند و اثبات‌شده برای ساخت اپلیکیشن‌های مقیاس‌پذیر، قابل نگهداری و تست‌پذیر است. با استفاده از این معماری در ASP.NET Core MVC و به کارگیری الگوهای طراحی مانند Repository، Unit of Work و تزریق وابستگی، می‌توان کدی تمیز، ماژولار و با ساختاری منسجم تولید کرد. اگرچه این رویکرد در ابتدا ممکن است به نظر پیچیده بیاید، اما سرمایه‌گذاری برای یادگیری و پیاده‌سازی صحیح آن، در بلندمدت به صرفه‌جویی در زمان و هزینه و افزایش کیفیت نهایی محصول منجر خواهد شد. این معماری، بنیادی محکم برای توسعه اپلیکیشن‌های سازمانی و پیچیده فراهم می‌کند و به تیم‌های توسعه اجازه می‌دهد تا با اطمینان بیشتری به گسترش و بهبود سیستم بپردازند.