我们什么时候需要数据类？

Question

我在使用asp.net内核。这里是与控制器一起使用模型的基本方法。

public class BookController : Controller
{
    private readonly ApplicationDbContext _context { get; set; }

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

    public IActionResult Create(Book model)
    {
        // adding new model
    }

    public IActionResult Edit(Book model)
    {
        // modifying the model
    }

    public IActionResult Delete(Book model)
    {
        // removing the model
    }
}

我的问题是:何时在控制器内实现代码？我什么时候应该在另一个类中实现它？

就像这样：

public interface IBook
{
    int Add(Book book);

    int Update(Book book);

    int Remove(Book book);
}

public class BookData : IBook
{
    private readonly ApplicationDbContext _context { get; set; }

    BookData(ApplicationDbContext context)
    {
        _context = context
    }

    public int Add(Book model)
    {
        // ...

        return _context.SaveChanges();
    }

    // other implements...
}

然后，在控制器内部调用它：

public IActionResult Create(Book model)
{
    var bookData = new BookData(_context);
    int result = bookData.Add(model);

    // ...
}

对于接口，我认为它可能对这种情况很有用:我有许多控制器需要相同的操作/方法名称。

示例：MessageController至少需要3个操作/方法(Create/Add、Edit/Update、Delete/Remove)。NotificationController课，CommentController课都一样.

因此，接口可以改进为：

public interface IMyService<T> where T : class
{
    int Add(T model);

    int Update(T model);

    int Remove(T model);
}

public class MyService<T> : IMyService<T> where T : class
{
    private readonly ApplicationDbContext _context { get; set; }

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

    public int Add(T model)
    {
        Type type = typeof(model);

        if (type == typeof(Book))
        {
            // adding new book model
        }
        else if (type == typeof(Comment))
        {
            // adding new comment model
        }

        // ...

        return -1;
    }

    // other implements...
}

我是不是误解了什么？

Answer 1

如果我用数据类正确地读取它，您实际上是指存储库(它是持久性层上的一个抽象)。您应该始终将持久化逻辑封装在类后面(无论是通过存储库模式、命令/查询模式还是请求处理程序)并使用它，而不是直接使用服务类中的上下文。

也就是说，您可以直接将BookData注入控制器，而不是ApplicationDbContext。您应该考虑在当前实现中丢失的一件事是工作单元模式。现在，每个添加都会立即保存数据。

这可能不是您想要的，所以您应该将_context.SaveChanges();移出Add/Remove/Update方法并显式调用它。这允许您插入10条记录，如果其中一条记录失败，则不会将任何内容保存到数据库中。

但是，如果在每次插入后调用_context.SaveChanges();，并且在第8条(10条)记录中得到一个错误，那么7条将被持久化，3条将丢失，并且得到不一致的数据。

控制器不应该包含任何逻辑，只需要对输入模型进行简短的验证(ModelState.IsValid检查)，如果可以的话，调用执行所有逻辑的服务并将结果报告给用户。只有在非常简单的教程和指南逻辑中，才会出于简单的原因将控制器操作放入控制器中。在实际应用程序中，您不应该这样做。控制器比服务类更难进行单元测试。