10 خطای رایج در ASP.NET Core MVC: شناخت، توضیح و راه‌حل

رفع خطاها و ارورها دات نت NET.

10 خطای رایج در ASP.NET Core MVC: شناخت، توضیح و راه‌حل

28 بازدید 0 نظر ۱۴۰۴/۰۵/۰۳

1. خطای 404 - Not Found (مسیر نامعتبر یا کنترلر/اکشن گمشده)

توضیح: این یکی از رایج‌ترین خطاهایی است که توسعه‌دهندگان و کاربران با آن مواجه می‌شوند. خطای 404 زمانی رخ می‌دهد که مرورگر نتواند منبع درخواستی (مانند یک صفحه وب یا فایل) را در سرور پیدا کند. در ASP.NET Core MVC، این معمولاً به دلیل آدرس URL اشتباه، نام اکشن یا کنترلر نادرست، یا عدم وجود فایل ویو مربوطه اتفاق می‌افتد.

مثال: فرض کنید آدرس /Home/About را درخواست می‌کنید، اما کنترلری به نام HomeController یا اکشنی به نام About وجود ندارد، یا فایل ویوی Views/Home/About.cshtml در دسترس نیست.

راه‌حل:

بررسی آدرس URL: مطمئن شوید که آدرس URL به درستی تایپ شده است و با مسیرهای تعریف شده در برنامه شما مطابقت دارد.
بررسی نام کنترلر و اکشن: اطمینان حاصل کنید که نام کنترلر (مثلاً HomeController) و نام اکشن (مثلاً About) به درستی نوشته شده‌اند (معمولاً در ASP.NET Core MVC به صورت Case-Insensitive هستند اما برای خوانایی بهتر، بهتر است از حروف بزرگ و کوچک استاندارد استفاده کنید).
بررسی مسیردهی (Routing): فایل Program.cs یا Startup.cs خود را برای تنظیمات مسیردهی بررسی کنید. مطمئن شوید که مسیرهای پیش‌فرض یا مسیرهای سفارشی شما به درستی تعریف شده‌اند.
```
app.MapControllerRoute(
    name: "default",
    pattern: "{controller=Home}/{action=Index}/{id?}");
```
بررسی وجود فایل ویو: مطمئن شوید که فایل ویو مربوطه (مثلاً Views/Home/About.cshtml) در مسیر صحیح خود قرار دارد.

2. خطای NullReferenceException (ارجاع تهی)

توضیح: این خطا زمانی رخ می‌دهد که شما سعی در دسترسی به عضوی (متد، ویژگی یا فیلد) از یک شیء دارید، در حالی که آن شیء null است. این خطا بسیار رایج است و می‌تواند در هر لایه‌ای از برنامه (مدل، کنترلر، ویو) اتفاق بیفتد.

مثال: فرض کنید یک شیء مدل را به ویو ارسال می‌کنید، اما یکی از ویژگی‌های آن شیء null است و شما بدون بررسی null بودن آن، سعی در نمایش یا دسترسی به آن ویژگی دارید.

// Controller
public IActionResult Details()
{
    Product product = null; // intentional null for demonstration
    return View(product);
}

// View
<p>Product Name: @Model.Name</p> // Throws NullReferenceException if Model is null

راه‌حل:

بررسی قبل از استفاده: همیشه قبل از استفاده از یک شیء یا ویژگی آن، null بودن آن را بررسی کنید.
```
@if (Model != null)
{
    <p>Product Name: @Model.Name</p>
}
else
{
    <p>Product not found.</p>
}
```
مقداردهی اولیه: اطمینان حاصل کنید که اشیاء به درستی مقداردهی اولیه شده‌اند.
استفاده از عملگر Safe Navigation (?.): این عملگر (موجود در C# 6 و بالاتر) به شما اجازه می‌دهد تا بدون نگرانی از NullReferenceException به اعضای یک شیء دسترسی پیدا کنید. اگر شیء null باشد، کل عبارت به null ارزیابی می‌شود.
```
<p>Product Name: @Model?.Name</p>
```
دیباگ کردن (Debugging): از دیباگر برای ردیابی نقطه دقیق بروز خطا و شناسایی شیء null استفاده کنید.

3. عدم تزریق وابستگی (Dependency Injection - DI) صحیح

توضیح: ASP.NET Core به شدت بر تزریق وابستگی تکیه دارد. این خطا زمانی رخ می‌دهد که شما سعی در استفاده از یک سرویس یا کلاس در کنترلر خود دارید، اما آن سرویس به درستی در کانتینر DI پیکربندی نشده است. نتیجه معمولاً خطایی مانند "Cannot resolve service for type 'YourService'" است.

مثال: اگر یک IMyService را در کنترلر خود تزریق کنید اما آن را در Program.cs یا Startup.cs ثبت نکرده باشید.

// Controller
public class HomeController : Controller
{
    private readonly IMyService _myService;

    public HomeController(IMyService myService) // Error if IMyService is not registered
    {
        _myService = myService;
    }
    // ...
}

راه‌حل:

ثبت سرویس در کانتینر DI: مطمئن شوید که تمام سرویس‌ها و وابستگی‌های مورد نیاز شما در Program.cs (یا Startup.cs در نسخه‌های قدیمی‌تر) به درستی ثبت شده‌اند.
```
// Program.cs
builder.Services.AddScoped<IMyService, MyService>(); // یا AddTransient, AddSingleton
```
- AddScoped: هر درخواست HTTP یک نمونه جدید دریافت می‌کند.
- AddTransient: هر بار که سرویس درخواست می‌شود، یک نمونه جدید ایجاد می‌شود.
- AddSingleton: تنها یک نمونه در طول عمر برنامه ایجاد می‌شود.
بررسی رابط و پیاده‌سازی: اطمینان حاصل کنید که رابط (Interface) و پیاده‌سازی (Implementation) به درستی مشخص شده‌اند.

4. مشکلات اعتبار سنجی (Model Validation)

توضیح: اعتبارسنجی مدل یک ویژگی حیاتی برای اطمینان از صحت داده‌های ورودی است. خطاهای اعتبارسنجی زمانی رخ می‌دهد که داده‌های ارسالی توسط کاربر با قوانین اعتبارسنجی تعریف شده در مدل شما مطابقت نداشته باشند. این مشکل به خودی خود خطا نیست، اما عدم مدیریت صحیح آن منجر به تجربه کاربری ضعیف یا مشکلات داده‌ای می‌شود.

مثال: یک فیلد Name در مدل شما با [Required] مشخص شده است، اما کاربر آن را خالی ارسال می‌کند.

// Model
public class ProductViewModel
{
    [Required(ErrorMessage = "نام محصول الزامی است.")]
    [StringLength(100, ErrorMessage = "نام محصول نمی‌تواند بیش از 100 کاراکتر باشد.")]
    public string Name { get; set; }
    // ...
}

// Controller
[HttpPost]
public IActionResult Create(ProductViewModel model)
{
    if (ModelState.IsValid) // If validation fails, IsValid is false
    {
        // Save data
    }
    return View(model); // Re-display form with errors
}

راه‌حل:

استفاده از ویژگی‌های اعتبارسنجی: از Data Annotations (مانند [Required], [StringLength], [Range], [EmailAddress]) در مدل‌های خود استفاده کنید.
بررسی ModelState.IsValid: همیشه در اکشن‌های HttpPost خود، ModelState.IsValid را بررسی کنید.
نمایش خطاهای اعتبارسنجی در ویو: از Tag Helpers مانند <span asp-validation-for="PropertyName"></span> و <div asp-validation-summary="All"></div> برای نمایش پیام‌های خطا به کاربر استفاده کنید.
اعتبارسنجی سمت کلاینت: برای بهبود تجربه کاربری، از jQuery Validation Unobtrusive در سمت کلاینت استفاده کنید (به طور پیش‌فرض در الگوهای پروژه ASP.NET Core MVC فعال است).

5. مشکلات ViewComponent و PartialView

توضیح: ViewComponents و PartialViews برای تقسیم‌بندی UI به قطعات قابل استفاده مجدد استفاده می‌شوند. خطاها می‌توانند زمانی رخ دهند که مسیرهای فراخوانی اشتباه باشند، مدل داده‌ای ارسال نشود یا ویو کامپوننت به درستی رجیستر نشده باشد.

مثال: فراخوانی یک ViewComponent با نام اشتباه، یا عدم ارسال پارامترهای لازم.

// Incorrect ViewComponent call in View
@await Component.InvokeAsync("NonExistentComponent")

راه‌حل:

مسیر و نام صحیح: مطمئن شوید که نام ViewComponent یا PartialView و مسیر فراخوانی آنها صحیح است.
- برای PartialView: @Html.Partial("_MyPartial") یا <partial name="_MyPartial" />
- برای ViewComponent: @await Component.InvokeAsync("MyViewComponent", new { param1 = value })
بررسی مدل ViewComponent: اطمینان حاصل کنید که مدل داده‌ای مورد انتظار ViewComponent به درستی ارسال می‌شود.
مکان قرارگیری: PartialViews معمولاً در پوشه Shared یا در پوشه مخصوص کنترلر مربوطه قرار می‌گیرند. ViewComponents باید در پوشه ViewComponents قرار گیرند.

6. خطاهای پیکربندی (Configuration Errors)

توضیح: ASP.NET Core از یک سیستم پیکربندی منعطف استفاده می‌کند که اطلاعات را از منابع مختلف (مانند appsettings.json, متغیرهای محیطی، خط فرمان) بارگذاری می‌کند. خطاهای پیکربندی زمانی رخ می‌دهد که شما سعی در خواندن یک کلید پیکربندی دارید که وجود ندارد، یا مقدار آن به درستی تجزیه نمی‌شود (مثلاً تبدیل از رشته به عدد).

مثال: سعی در خواندن یک کلید از appsettings.json که در آن فایل تعریف نشده است.

// appsettings.json
// { "MySetting": "Value" }

// Code attempting to read non-existent key
var value = _configuration["NonExistentKey"]; // value will be null

راه‌حل:

بررسی نام کلید: اطمینان حاصل کنید که نام کلید پیکربندی به درستی نوشته شده است (Case-Sensitive).
بررسی فایل appsettings.json: مطمئن شوید که فایل appsettings.json به درستی فرمت شده است (JSON معتبر).
مقادیر پیش‌فرض: در صورت امکان، هنگام خواندن مقادیر پیکربندی، مقادیر پیش‌فرض را ارائه دهید یا بررسی null بودن انجام دهید.

استفاده از Options Pattern: برای مدیریت بهتر پیکربندی‌های پیچیده و کاهش خطاهای NullReferenceException، از الگوی Options استفاده کنید.

// MyOptions.cs
public class MyOptions
{
    public string MySetting { get; set; }
}

// Program.cs
builder.Services.Configure<MyOptions>(builder.Configuration.GetSection("MySection"));

// In a class using MyOptions
public class MyClass
{
    private readonly MyOptions _options;

    public MyClass(IOptions<MyOptions> options)
    {
        _options = options.Value;
    }
}

7. مشکلات مدیریت حالت (State Management)

توضیح: در وب، به دلیل stateless بودن پروتکل HTTP، مدیریت حالت بین درخواست‌ها می‌تواند چالش‌برانگیز باشد. خطاهایی مانند از دست دادن داده‌ها بین درخواست‌ها، یا استفاده نادرست از Session/TempData/ViewData/ViewBag می‌توانند منجر به مشکلات عملکردی یا از دست رفتن اطلاعات شوند.

مثال: استفاده از TempData برای ذخیره اطلاعاتی که نیاز به ماندگاری طولانی‌تری دارند، یا عدم بررسی null بودن TempData قبل از استفاده.

راه‌حل:

شناخت ابزارهای مدیریت حالت:
- TempData: برای انتقال داده بین دو درخواست متوالی (مثلاً پس از Redirect). پس از خوانده شدن یک بار، پاک می‌شود.
- ViewBag/ViewData: برای انتقال داده از کنترلر به ویو در همان درخواست.
- Session: برای ذخیره داده برای یک کاربر خاص در طول چندین درخواست (نیاز به پیکربندی).
- کوکی‌ها (Cookies): برای ذخیره داده‌های کوچک در مرورگر کاربر.
- ذخیره‌سازی سمت کلاینت (Local Storage/Session Storage): برای ذخیره‌سازی داده‌های سمت کلاینت.
استفاده صحیح: ابزار مناسب را برای هر مورد استفاده انتخاب کنید.
بررسی null بودن: همیشه قبل از استفاده از داده‌های ذخیره شده در TempData یا Session، null بودن آنها را بررسی کنید.
پیکربندی Session: اگر از Session استفاده می‌کنید، مطمئن شوید که آن را در Program.cs یا Startup.cs پیکربندی کرده‌اید.

8. خطای CORS (Cross-Origin Resource Sharing

توضیح: خطای CORS زمانی رخ می‌دهد که یک درخواست وب (معمولاً AJAX از جاوااسکریپت) از یک مبدأ (Origin) به مبدأ دیگری ارسال شود و سرور مقصد اجازه آن را ندهد. این یک ویژگی امنیتی مرورگر است که از حملات XSS جلوگیری می‌کند.

مثال: یک برنامه Single Page Application (SPA) که در http://localhost:3000 اجرا می‌شود، سعی در فراخوانی یک API در http://localhost:5000 دارد.

راه‌حل:

پیکربندی CORS در سرور: در ASP.NET Core، می‌توانید CORS را با استفاده از Middleware پیکربندی کنید.

// Program.cs
var MyAllowSpecificOrigins = "_myAllowSpecificOrigins";

builder.Services.AddCors(options =>
{
    options.AddPolicy(name: MyAllowSpecificOrigins,
                      policy =>
                      {
                          policy.WithOrigins("http://localhost:3000",
                                              "http://www.yourdomain.com") // Add allowed origins
                                .AllowAnyHeader()
                                .AllowAnyMethod();
                      });
});

// In app.UseRouting() and app.UseEndpoints() block
app.UseCors(MyAllowSpecificOrigins);

AllowAnyOrigin (احتیاط!): برای محیط‌های توسعه، می‌توانید AllowAnyOrigin() را استفاده کنید، اما در محیط تولید باید مبدأهای مجاز را به دقت مشخص کنید.
بررسی درخواست‌های Preflight: برای درخواست‌های پیچیده (مانند PUT، DELETE یا درخواست‌هایی با هدرهای سفارشی)، مرورگر ابتدا یک درخواست OPTIONS (preflight request) ارسال می‌کند. مطمئن شوید که سرور به این درخواست‌ها پاسخ صحیح می‌دهد.

9. خطاهای پایگاه داده (Database Errors)

توضیح: این خطاها مربوط به تعامل با پایگاه داده هستند و می‌توانند شامل موارد زیر باشند: مشکلات اتصال، خطاهای SQL، نقض محدودیت‌ها (Unique Constraint, Foreign Key), یا مشکلات مهاجرت (Migrations).

مثال: تلاش برای ذخیره یک رکورد با مقدار تکراری در یک ستون منحصر به فرد (Unique Key Constraint Violation).

راه‌حل:

بررسی Connection String: مطمئن شوید که رشته اتصال به پایگاه داده در appsettings.json صحیح و معتبر است.

مدیریت خطا در EF Core: از بلوک‌های try-catch برای مدیریت خطاهای پایگاه داده استفاده کنید، به خصوص هنگام انجام عملیات CRUD.

try
{
    _context.Products.Add(product);
    await _context.SaveChangesAsync();
}
catch (DbUpdateException ex)
{
    // Log the exception, handle specific errors (e.g., duplicate key)
    ModelState.AddModelError("", "خطایی در ذخیره اطلاعات رخ داد. لطفاً مجدداً تلاش کنید.");
    // Or specific error for duplicate
    if (ex.InnerException?.Message.Contains("duplicate key") == true)
    {
        ModelState.AddModelError("Name", "نام محصول تکراری است.");
    }
    return View(product);
}

بررسی Migration‌ها: اطمینان حاصل کنید که Migration‌ها به درستی اعمال شده‌اند و ساختار پایگاه داده با مدل‌های Entity Framework Core شما مطابقت دارد.
لاگ‌برداری: لاگ‌های پایگاه داده را برای شناسایی کوئری‌های مشکل‌ساز یا خطاهای دقیق بررسی کنید.

10. مشکلات Caching (کشینگ)

توضیح: کشینگ برای بهبود عملکرد برنامه‌های وب ضروری است، اما پیکربندی نادرست یا استفاده نامناسب از آن می‌تواند منجر به نمایش داده‌های منسوخ شده یا افزایش مصرف حافظه شود.

مثال: کش کردن یک قطعه از UI با داده‌های پویا برای مدت طولانی، که باعث می‌شود کاربران همیشه اطلاعات قدیمی را ببینند.

راه‌حل:

انتخاب استراتژی کش مناسب:
- In-Memory Caching: برای داده‌های کوچک و پرکاربرد در حافظه سرور.
- Distributed Caching (Redis, SQL Server): برای برنامه‌هایی با چندین سرور یا نیاز به کش مشترک.
- Response Caching: کش کردن پاسخ‌های HTTP کامل.
تنظیمات انقضا (Expiration): زمان انقضا را بر اساس فرکانس تغییر داده‌ها به درستی تنظیم کنید.
```
// In-memory caching example
_cache.Set("MyData", data, new MemoryCacheEntryOptions
{
    AbsoluteExpirationRelativeToNow = TimeSpan.FromMinutes(5)
});
```
کش‌زدایی (Cache Invalidation): مکانیزمی برای ابطال کش (پاک کردن داده‌های کش شده) هنگام تغییر داده‌های اصلی پیاده‌سازی کنید.
استفاده از Tag Helpers مربوط به کش: برای کش کردن بخش‌هایی از ویو:
HTML
```
<cache expires-after="@TimeSpan.FromMinutes(10)">
    @* Content to cache *@
</cache>
```
پایش کش: مصرف حافظه و نرخ برخورد (Hit Rate) کش خود را پایش کنید تا از کارایی آن مطمئن شوید.

نتیجه‌گیری:

شناخت و درک این ۱۰ خطای رایج در ASP.NET Core MVC، گام مهمی در جهت تبدیل شدن به یک توسعه‌دهنده کارآمدتر است. با پیاده‌سازی راه‌حل‌های ارائه شده و استفاده از ابزارهای دیباگینگ و لاگ‌برداری، می‌توانید بسیاری از این مشکلات را قبل از اینکه به کاربران نهایی برسند، شناسایی و برطرف کنید. به یاد داشته باشید که تمرین و تجربه، کلید تسلط بر فریم‌ورک‌های پیچیده‌ای مانند ASP.NET Core MVC است.

لینک استاندارد شده: n0yE