【发布时间】:2019-10-24 18:21:31
【问题描述】:
我正在创建一个 asp.net 核心 Web 应用程序,并且我正在尝试为我的数据库上下文创建一个接口,以便在我的业务逻辑层中使用它。界面制作如下:
public interface IAppDbContext
{
public DbSet<Country> Countries { get; set; }
public DbSet<City> Cities { get; set; }
Task<int> SaveChangesAsync(CancellationToken cancellationToken);
}
接口的实现如下:
public class AppDbContext : IdentityDbContext<ApplicationUser, ApplicationRole, string> , IAppDbContext
{
public AppDbContext(DbContextOptions<AppDbContext> options)
: base(options)
{
}
public DbSet<Country> Countries { get; set; }
public DbSet<City> Cities { get; set; }
}
问题是当我注入接口并尝试使用_context.Users时,它显示的错误是:
'IAppDbContext' does not contain a definition for 'Users' and no accessible extension method 'Users' accepting a first argument of type 'IAppDbContext' could be found (are you missing a using directive or an assembly reference?).
我知道在实现上,_context.Users 来自父类IdentityDbContext,但是我怎样才能将它也添加到接口中以便我可以使用它呢?谢谢!
【问题讨论】:
-
这里没有实现接口的意义。一个接口是为了让多个实现都符合一个单一的合同。这里永远不会有多种实现——只有你的一个上下文类。
-
我正在尝试在我的应用程序中实现github.com/JasonGT/NorthwindTraders(干净的架构),他使用业务层中的 dbcontext 接口和不同项目的实现。我相信他采用这种方法进行单元测试。由于我对编程很陌生,您认为这没有必要,我可以直接从应用层引用持久性?非常感谢!
-
测试不需要。仅仅因为有人在网上扔了一些代码并不意味着它很好,或者你应该遵循同样的方式。
-
其中很多可能是不必要的。你不需要接口。您不应该将存储库/工作单元模式与 EF 等 ORM 一起使用。如果您想要抽象,请使用服务层或更高级的模式,如 CQRS 或微服务。虽然,这应该随着您的应用程序的开发而流畅地发生。换句话说,从小处着手。创建最基本的功能单元,然后根据需要重构为模式。 “必要”部分是关键。
标签: c# asp.net-core asp.net-identity