ASP.NET MVC中CRUD数据访问方法的正确放置位置咨询

Great question! Writing Entity Framework CRUD operations directly in your ASP.NET MVC Controllers is not a recommended practice—let me break down why, and walk you through the standard approach:

Why putting EF code in Controllers is a bad idea #

• Violates the Single Responsibility Principle: Controllers are meant to handle request routing, model validation, and returning appropriate views/responses. Tacking on data access logic muddles their core purpose.
• Hard to test: If your Controller directly depends on DbContext, unit testing requires a real database connection. You can't easily mock the data layer to isolate and test Controller behavior.
• Code duplication: If multiple Controllers need to interact with the same entity, you'll end up copying and pasting CRUD code everywhere—making updates and bug fixes a nightmare.

We use a layered architecture to separate concerns, making code cleaner, more maintainable, and testable. Here's how it works:

1. Data Access Layer: Repository Pattern #

The Repository pattern wraps all EF data access logic into dedicated classes, one per entity. This centralizes data operations and abstracts away EF specifics from the rest of your app.

First, define an interface for your repository (this makes mocking easier for testing):

public interface IProductRepository
{
    Product GetById(int id);
    IEnumerable<Product> GetAll();
    void Add(Product product);
    void Update(Product product);
    void Delete(int id);
}

Then implement the interface using EF:

public class ProductRepository : IProductRepository
{
    private readonly AppDbContext _dbContext;

    // Inject DbContext via constructor (use dependency injection!)
    public ProductRepository(AppDbContext dbContext)
    {
        _dbContext = dbContext;
    }

    public Product GetById(int id)
    {
        return _dbContext.Products.Find(id);
    }

    public IEnumerable<Product> GetAll()
    {
        return _dbContext.Products.ToList();
    }

    public void Add(Product product)
    {
        _dbContext.Products.Add(product);
        _dbContext.SaveChanges();
    }

    // Implement other CRUD methods similarly...
}

2. Business Logic Layer: Service Layer #

If your app has business rules (like validating product stock before creating an order, or calculating discounts), these belong in a Service layer. Services act as a middleman between Controllers and Repositories, encapsulating business logic.

Example service interface and implementation:

public interface IProductService
{
    Product GetProductById(int id);
    IEnumerable<Product> GetAllProducts();
    void CreateProduct(ProductCreateViewModel model);
    // Add methods for business-specific operations
}

public class ProductService : IProductService
{
    private readonly IProductRepository _productRepository;

    public ProductService(IProductRepository productRepository)
    {
        _productRepository = productRepository;
    }

    public Product GetProductById(int id)
    {
        return _productRepository.GetById(id);
    }

    public void CreateProduct(ProductCreateViewModel model)
    {
        // Add business validation here (e.g., check if product name is unique)
        if (_productRepository.GetAll().Any(p => p.Name == model.Name))
        {
            throw new InvalidOperationException("Product name already exists!");
        }

        var product = new Product
        {
            Name = model.Name,
            Price = model.Price,
            StockQuantity = model.StockQuantity
        };

        _productRepository.Add(product);
    }
}

3. Controller Layer: Use Dependency Injection #

Controllers should only handle request/response flow. Inject your Service into the Controller, and use it to interact with the data layer without knowing the details of EF or Repositories.

public class ProductsController : Controller
{
    private readonly IProductService _productService;

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

    public IActionResult Index()
    {
        var products = _productService.GetAllProducts();
        var viewModel = products.Select(p => new ProductListViewModel
        {
            Id = p.Id,
            Name = p.Name,
            Price = p.Price
        }).ToList();
        return View(viewModel);
    }

    [HttpPost]
    public IActionResult Create(ProductCreateViewModel model)
    {
        if (!ModelState.IsValid)
        {
            return View(model);
        }

        try
        {
            _productService.CreateProduct(model);
            return RedirectToAction(nameof(Index));
        }
        catch (InvalidOperationException ex)
        {
            ModelState.AddModelError(string.Empty, ex.Message);
            return View(model);
        }
    }
}

Bonus: Unit of Work (Optional) #

If you need to perform multiple database operations in a single transaction (e.g., adding a product and updating a category), use the Unit of Work pattern to wrap multiple Repositories and handle SaveChanges() once. This ensures data consistency.

Example Unit of Work implementation:

public interface IUnitOfWork : IDisposable
{
    IProductRepository Products { get; }
    ICategoryRepository Categories { get; }
    int Complete();
}

public class UnitOfWork : IUnitOfWork
{
    private readonly AppDbContext _dbContext;

    public IProductRepository Products { get; private set; }
    public ICategoryRepository Categories { get; private set; }

    public UnitOfWork(AppDbContext dbContext)
    {
        _dbContext = dbContext;
        Products = new ProductRepository(_dbContext);
        Categories = new CategoryRepository(_dbContext);
    }

    public int Complete()
    {
        return _dbContext.SaveChanges();
    }

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

You'd then inject IUnitOfWork into your Service instead of individual Repositories, and call Complete() after all operations are done.

Final Notes #

This layered approach keeps your code organized, testable, and easy to maintain. You can mock Repositories/Services in unit tests, reuse business logic across Controllers, and update data access logic without touching your UI layer.

内容的提问来源于stack exchange，提问作者Arad