ASP.NET Core MVC中模型实例化与初始化的最佳实践咨询

Hey there! Let's walk through your two approaches and figure out which one fits better with ASP.NET MVC best practices.

First, let's anchor back to the core MVC principle you noted: controllers are responsible for coordinating data and selecting what gets passed to the view, while models (and ViewModels, in this case) should focus on their specific roles—either holding data or encapsulating business logic. When it comes to ViewModels specifically, their sweet spot is being a pure data carrier for the view—they shouldn't handle data retrieval, mapping, or any heavy logic.

Let's break down your options #

1. Controller handles logic (Recommended Approach) #

This aligns perfectly with MVC's separation of concerns:

• Your DepartmentViewModel is a clean, simple POCO (Plain Old CLR Object) with only the property the view needs. No dependencies, no logic—its sole job is to move data to the view.
• The controller takes on its intended role: it fetches data from the repository, uses the mapper to convert entities to DTOs, and populates the ViewModel before passing it along.
• Better testability: You can write unit tests for the controller's logic without having to mock dependencies for the ViewModel. Since the ViewModel has no behavior, it doesn't need testing on its own.
• Flexibility: If you ever need to adjust how you fetch or map data (like adding filters or switching data sources), you only modify the controller (or even extract that logic to a service layer) without touching the ViewModel.

Here's your code again for reference:

// ViewModel - Pure data carrier
public class DepartmentViewModel {
    public IEnumerable<DepartmentDto> lstDepartments { get; set; }
}

// Controller - Coordinates data flow
public class DepartmentController : Controller {
    private readonly IUnitOfWork _work;
    private readonly IMapper _mapper;
    public DepartmentController(IUnitOfWork work, IMapper mapper) {
        _work = work;
        _mapper = mapper;
    }
    public async Task<IActionResult> Index(DepartmentViewModel viewmodel) {
        var lstAllDepartments = _work.DepartmentRepository.GetAll();
        var lstDepartmentsForViewmodel = _mapper.Map<IEnumerable<Core.Entities.Department>, IEnumerable<DepartmentDto>>(lstAllDepartments);
        viewmodel.lstDepartments = lstDepartmentsForViewmodel;
        return View(viewmodel);
    }
}

2. ViewModel contains logic (Not Recommended) #

Putting data retrieval and mapping in the ViewModel breaks MVC's separation of concerns and creates avoidable headaches:

• The ViewModel now has two conflicting jobs: carrying data and fetching/mapping it—violating the Single Responsibility Principle. This makes it harder to maintain as your app scales.
• Injecting dependencies like IUnitOfWork and IMapper into the ViewModel couples it tightly to your data access layer, making it less reusable. If you need this ViewModel elsewhere (like a different controller or API endpoint), you'll have to pass those dependencies every time.
• Worse testability: Testing the ViewModel now requires mocking IUnitOfWork and IMapper, adding unnecessary complexity to your test suite.

A Further Optimization #

To make this even cleaner, you could extract the data retrieval and mapping logic into a dedicated service class (e.g., IDepartmentService). This keeps your controller thin and moves business/data logic into a layer that's easier to test and reuse:

// Service Interface
public interface IDepartmentService {
    IEnumerable<DepartmentDto> GetAllDepartments();
}

// Service Implementation
public class DepartmentService : IDepartmentService {
    private readonly IUnitOfWork _work;
    private readonly IMapper _mapper;
    public DepartmentService(IUnitOfWork work, IMapper mapper) {
        _work = work;
        _mapper = mapper;
    }
    public IEnumerable<DepartmentDto> GetAllDepartments() {
        var departments = _work.DepartmentRepository.GetAll();
        return _mapper.Map<IEnumerable<Core.Entities.Department>, IEnumerable<DepartmentDto>>(departments);
    }
}

// Updated Controller
public class DepartmentController : Controller {
    private readonly IDepartmentService _departmentService;
    public DepartmentController(IDepartmentService departmentService) {
        _departmentService = departmentService;
    }
    public async Task<IActionResult> Index() {
        var viewModel = new DepartmentViewModel {
            lstDepartments = _departmentService.GetAllDepartments()
        };
        return View(viewModel);
    }
}

This way, every component has a clear, focused job:

• Controller: Handles HTTP requests, calls the service, and returns the view with the ViewModel.
• Service: Manages data retrieval, mapping, and any business rules.
• ViewModel: Purely carries data to the view.

内容的提问来源于stack exchange，提问作者Trystan Lapinig-Wilcock