应该如何在 ASP NET Core MVC 中检索数据？答案

【问题标题】：How is data supposed to be retrieved in ASP NET Core MVC?应该如何在 ASP NET Core MVC 中检索数据？
【发布时间】：2021-03-04 01:17:58
【问题描述】：

我正在开发一个 ASP NET Core MVC 项目（使用实体框架和身份，如果这对这个答案有影响的话），我对我在不同网站上阅读的所有内容感到有点困惑。有人说业务逻辑应该在模型中，但其他人则显示正在创建的 databasecontext.cs 和业务逻辑在其中。将它放在模型中对我来说很有意义，但我现在的问题是数据库是在 startup.cs 服务中设置的，所以现在选项是从服务发送的，我不能真正为每个人创建一个新连接方法调用。

供参考：

Startup.cs

services.AddDbContext<DatabaseContext>( options =>
{
     options.UseSqlServer(
          Configuration.GetConnectionString("DefaultConnection"),
          b => b.MigrationsAssembly(typeof(DatabaseContext).Assembly.FullName)
     );
});

模型 - User.cs

namespace SPPP.Models
{
    public class User : IdentityUser
    {
        [Required(ErrorMessage = "Full Name Required")]
        [MaxLength(80)]
        public string FullName { get; set; }

        [Required(ErrorMessage = "Role Required")]
        [MaxLength(10)]
        public string Role { get; set; }

        [Required(ErrorMessage = "Status Required")]
        [MaxLength(10)]
        public string Status { get; set; }

        public IList<User_Group> User_group { get; set; }

        public User()
        {

        }
    }
}

DatabaseContext.cs

namespace SPPP.Data
{
    public class DatabaseContext : IdentityDbContext
    {

        public DbSet<User> Users { get; set; }
        public DbSet<Group> Groups { get; set; }
        public DbSet<File> Files { get; set; }
        public DbSet<User_Group> User_groups { get; set; }

        public DatabaseContext(DbContextOptions<DatabaseContext> options) : base(options)
        {

        }

        protected override void OnModelCreating(ModelBuilder builder)
        {
            ...
        }
    }
}

是否有关于如何设置它以便在模型中发生业务逻辑的参考？

【问题讨论】：

“有人说业务逻辑应该在模型中，但其他人则显示正在创建的 databasecontext.cs 并且业务逻辑在其中”...这是因为人们对如何操作有不同的看法来构建它们的应用程序，并且不同的方法可能适用于不同的情况。所有架构/设计决策都是一种或另一种权衡。您只需检查每种情况的利弊，确定您认为在当前情况下最好的方法（以及它是否适合您的更广泛的方法，也许），然后去做。
“我真的无法为每个方法调用创建一个新连接。”...您是否发现您的应用程序需要连接到多个数据库？否则我不明白为什么这很重要。创建连接几乎肯定应该是您的数据库层关注的问题，而不是业务逻辑 - 至少我对此有非常强烈的看法。
可能是的，如果那是你想使用它的地方。依赖注入功能应该能够帮助您实现这一目标。
在一些流行的桌面开发模式（例如 MVVM）中，与 ASP.NET MVC 中使用的 ViewModel 相比，ViewModel 扮演的角色不同。通常在桌面应用程序中使用的 ViewModel 中，我们将服务作为依赖项注入。在 ASP.NET MVC 中，ViewModel 只是包含数据，它很像模型，但是因为它绑定到视图，所以我们称之为 ViewModel。服务通常不在那里注入，而是在控制器和页面中（对于剃刀页面）。当然，您可以设计您的 ViewModel 来使用服务，但最终您必须将虚拟机注入到控制器/页面中。
Hopeless 在这里提出了一个很好的观点——如果你打算使用（例如）你的 User 类作为视图的视图模型（看起来你可能会这样做，因为它具有这些验证属性它），那么将其保留为仅包含属性的简单数据传输对象可能是有意义的，并具有一个单独的 UserLogic 类，该类使用该对象并与数据库通信并实现所需的任何中间逻辑和处理。

标签： c# asp.net-mvc asp.net-core asp.net-mvc-3 entity-framework-core

【解决方案1】：

当涉及到 ASP.NET MVC 时，您不应该在模型中执行业务逻辑。您的业务逻辑应保存在服务类中。尽管您可以以不同的方式构建它。这是一个常见的例子：

前：

public class UserService : IUserService
{
    private readonly DatabaseContext _context;
    
    pubic UserService(DatabaseContext context) 
    {
        _context = context;
    }

    public async Task<User> GetUsersAsync() 
    {
        // Do some business logic here


        // Get data from DB like this:
        var users = await _context.Users.ToListAsync();

    }
}

然后，您的控制器将在构造函数中注入 IUserService。然后，您可以从您的控制器中的服务类调用任何方法。

别忘了在 startup.cs 的 ConfigureServices() 方法中注册你的服务。

如果您不想将业务逻辑与从同一位置的 dbcontext 获取数据混合在一起，您还可以将逻辑分离以在单独的类（如 DataAccess 层）中获取数据。有些人也喜欢使用存储库模式，这没问题，但没有必要，因为默认情况下 EF 已经在内部实现了存储库模式。

【讨论】：