جدا سازی Endpoint و لایه Presentation در NET 7.

جدا سازی Endpoint و لایه Presentation ?

شاید برای شما سوال باشد که آیا این دو با هم پیاده سازی نمیشوند؟ اگر بخواهیم به سرعت پاسخ دهیم جواب مثب است، اما با پیاده سازی این دو با هم ممکن است به یک مشکل اساسی روبرو شویم.

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

اخیراً در پروژه ها بیشتر روی clean architecture تمرکز کرده ام و می توانم بگویم که طرفدار واقعی این معماری هستم.

پس بیایید نگاهی به این معماری بندازیم:

در معماری پیازی یا Onion architecture ممکن است پروژه های زیر را داشته باشیم:

• Presentation
• Application
• Domain
• Infrastrucure
• Cross-Cussting edge

در معماری بالا سعی کردم تمامی موارد مربوط به پیاده سازی معماری پیازی را بصورت خلاصه به تصویر بکشم.

خب چرا لایه Presentation و Web/Api از هم جدا شدند؟

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

مسئله:

بیایید تصور کنیم که یک کنترلر مثل زیر داریم:

public class HomeController : ControllerBase
{
    private readonly DbContext _dbContext;
    public HomeController (DbContext dbContext)
    {
      _dbContext=dbContext;
    }

    // Remaining code removed for brevity
}

معمولاً کنترلرها و وب در لایه presentation پیاده‌سازی می‌شوند، اما اجازه دهید مثلای بزنم، فرض کنید توسعه‌دهنده جدیدی سعی می‌کند نمونه‌ای از DBcontext ایجاد کند در این کنترلر ایجاد کند، با ایجاد آن میتواند به پایگاه داده دسترسی داشته باشد، این نوع طراحی اصول CQRS را نقض می‌کند.

راه حل:

برای جلوگیری از این موضوع، می‌توانیم Web API و لایه presentation را جدا کنیم.

همانطور که در شکل زیر میبینید، دو پروژه به نامهای Presentation و Api را توسعه داده ام.

بیایید نگاهی به کدهای داخل هر یک بیندازیم، اول از همه، اجازه دهید نگاهی به رابط IAssmblyReference.cs بیندازیم:

namespace OnionArchitecture.Presentation;
/// <summary>
/// This empty interface will be registered by Api
/// </summary>
public interface IAssemblyReference
{

}

این فقط یک interface خالی است که program.cs به آن ارجاع شده است تا لایه presentation ما را در Api ثبت کند.

قدم بعدی ثبت IAssemblyReference در API است.

var builder = WebApplication.CreateBuilder(args);
// Add services to the container.
builder.Services.AddControllers()
    .AddApplicationPart(typeof(IAssemblyReference).Assembly);
// Remaining code removed for brevity

با افزودن AddApplicationPart همه کنترلرها و غیره را از لایه Presentation در API خود ثبت می کنیم.

نتیجه:

• با این رویکرد می توانیم به پیاده سازی CQRS دست پیدا کنیم و از دسترسی مستقیم به پایگاه داده در کنترلر اجتناب کنیم.
• ما فقط یک class library جدید ایجاد کردیم که شامل کنترلرها می شود و سپس آن را در لایه Web/API ثبت می کنیم.
• با این رویکرد با ورود یک برنامه نویس تازه کار به پروژه، از دسترسی مستقیم کنترلر به dbContext را اجتناب خواهیم کرد.