ABP框架 - 数据过滤

文档目录

 

本节内容:

 

简介

通常都会用到软删除模式(不把一个实体从数据库中删除,只是给它做个标志“deleted“),如果一个实体被软删除,它不应被应用意外地获取,为了提供这种功能,我们应该为每个select查询的Sql语句的where里添加类似”IsDeleted=false“的条件,这很无聊,但又很重要也容易忘记,所以需要一个自动的方式。

ABP提供数据过滤,它可以根据这些规则自动过滤查询。已经有些预定义的过滤,但你也可以创建你自己的过滤。

 

预定义过滤

ISoftDelete

软删除过滤用来在查询数据库时,自动过滤(从结果中抽取)已删除的实体。如果一个实体可以被软删除,它必须实现ISoftDelete接口,该接口只定义了一个IsDeleted属性,例如:

public class Person : Entity, ISoftDelete
{
    public virtual string Name { get; set; }

    public virtual bool IsDeleted { get; set; }
}

实质上不会从数据库里删除一个Person实体,当需要删除它时,只是把它的IsDeleted属性设置为true,你可以使用IRepository.Delete方法(你可以手动设置IsDeleted为true,但Delete方法更自然和推荐的方式)来完成。

实现ISoftDelete之后,当你从数据库获取Person列表,软删除的人员不会被获取,此处有一个示例类,使用一个person仓储获取所有人员:

public class MyService
{
    private readonly IRepository<Person> _personRepository;

    public MyService(IRepository<Person> personRepository)
    {
        _personRepository = personRepository;
    }

    public List<Person> GetPeople()
    {
        return _personRepository.GetAllList();
    }
}

GetPeople方法仅获取全部IsDeleted=false(不是delete)的Person。所有的仓储方法和导航属性都工作正常。我们可以添加一些其实where条件、连接等,它会自动添加IsDeleted=false条件到生成的Sql查询。

何时可用?

ISoftDelete过滤一直可用,除非你显式禁用它。

 边注:如果你实现IDeletionAudited(它扩展了ISoftDelete),ABP同样也会自动给删除时间和删除用户Id赋值。

 

IMustHaveTenant

如果你正在创建多租户应用并存储所有租户数据在一个数据库里,你明确地不想一个租户的数据意外地被另一个租户看到,这种情况下你可用IMustHaveTenant。例如:

public class Product : Entity, IMustHaveTenant
{
    public int TenantId { get; set; }

    public string Name { get; set; }
}

IMustHaveTenant定义了TenantId,区别不同的租户实体。ABP默认情况下使用IAbpSeesion获取当前TenantId,并自动为当前租户过滤查询。

何时可用?

IMustHaveTenant默认可用。

如果当前用户尚未登录系统或当前是个宿主用户(宿主用户是一个更高级别的用户,它管理租户和租户数据),ABP自动禁用IMustHaveTenant过滤,因此,可以获取所有租户的所有数据。注意:这与安全性无关,你应当一直授权敏感数据。

 

IMayHaveTenant

如果一个实体类被租户和宿主共享(也就是说一个实体对象可被租户或宿主拥有),你可以使用IMayHaveTenant过滤。IMayHaveTenant接口定义了TenantId,但它是可空的。

public class Role : Entity, IMayHaveTenant
{
    public int? TenantId { get; set; }

    public string RoleName { get; set; }
}

一个null值表示这是个宿主实体,一个非null值表示这个实体被Id为TenantId的租户拥有。默认情况下,ABP使用IAbpSeesion获取当前TenantId。IMayHaveTenant过滤不像IMustHaveTenant那么通用,但在实体类型通用宿主和租户时,需要它。

如何可用?

IMayHaveTenant一直可用,除非你显式禁用它。

 

禁用过滤

调用DisableFilter方法可以禁用每个工作单元的一个过滤,如下:

var people1 = _personRepository.GetAllList();

using (_unitOfWorkManager.Current.DisableFilter(AbpDataFilters.SoftDelete))
{
    var people2 = _personRepository.GetAllList();                
}

var people3 = _personRepository.GetAllList();

DisableFilter接受一个或多个过滤名称组成的字符串,AbpDataFilters.SoftDelete是个字符串常量,它代表ABP的软删除过滤。

people2将包含被软删除的people,people1和people3只包含未被软删除的people。使用using声明,你可以在using域内禁用一个过滤。如果不使用using声明,过滤会被禁用,直到当前工作单元结束或是你显示启用这个过滤。

你可以注入IUnitOfWorkManager,然后像上例那样使用,如果你的类继承自特殊的基类(如应用服务,AbpController,AbpApiController...),你也可以直接使用CurrentUnitOfWork属性。

关于using声明

如果一个过滤是启用的,当你使用using声明,调用DisableFilter方法,这个过滤会被禁用,然后在using声明之后,自动地被启用。但是如果这个过滤是在使用using声明前,就是禁用的,那么DisableFilter什么也不做,在using声明之后,它仍然是禁用的。

关于多租户

你可以禁用多租户过滤来查询所有租户的数据,但这只对一个数据库有效。如果你为每个租户使用分离的数据库,禁用过滤就无法帮助你获取所有租户的数据,因为数据在不同的数据库甚至是不同的服务器,更多信息查看多租户文档

 

启用过滤

在一个工作单元里,你可以使用EnableFilter方法启用一个过滤。相似于(也相反于)DisableFilter。EnableFilter也在使用using声明时,返回可释放对象,用来在有需要的情况下重新禁用过滤。

 

设置过滤参数

一个过滤可以参数化,IMusthaveTenant过滤就是一个例子,因为当前租户的Id在运行时才能检测到。对于此类过滤,如果有需要,我们可以修改过滤值,如:

CurrentUnitOfWork.SetFilterParameter("PersonFilter", "personId", 42);

另一个例子:为IMayHaveTenant过滤,设置租户Id:

CurrentUnitOfWork.SetFilterParameter(AbpDataFilters.MayHaveTenant, AbpDataFilters.Parameters.TenantId, 42);

SetFilterParameter方法也返回一个IDisposeble,所以使用一个using声明,让它自动在声明之后恢复原值。

 

SetTenantId 方法

虽然你可以使用SetFilterParameter方法,为MayHaveTenant和MusthaveTenant修改过滤值,但修改租户过滤有一个更好的方式:SetTenantId()。SetTenantId为这两个过滤修改参数值,并且单数据库或每个租户一个数据库都有效。所以,总是推荐用SetTenantId修改租户过滤的参数值。查看多租户文档获取更多信息。

 

自定义过滤

为自定义过滤并整合到ABP,首先,定义一个接口,它将被使用这个过滤的实体实现。假设我们要通过PersonId自动过滤实体,接口示例:

public interface IHasPerson
{
    int PersonId { get; set; }
}

然后我们为需要的实体实现这个接口,实体示例:

public class Phone : Entity, IHasPerson
{
    [ForeignKey("PersonId")]
    public virtual Person Person { get; set; }
    public virtual int PersonId { get; set; }

    public virtual string Number { get; set; }
}

因为ABP使用EntityFramework.DynamicFilters,我们使用它的规则来定义这个过滤,在我们的DbContext类里,我们重写OnModelCreating,如下所示:

protected override void OnModelCreating(DbModelBuilder modelBuilder)
{
    base.OnModelCreating(modelBuilder);

    modelBuilder.Filter("PersonFilter", (IHasPerson entity, int personId) => entity.PersonId == personId, 0);
}

“PersonFilter”是这个过滤的唯一的名称,第二个参数表明过滤的接口和过滤参数PersonId(如果过滤不可参数化,可不用),最后一个参数是personId的默认值。

最后在我们模块的PreInitialize方法里,注册这个过滤到ABP工作单元系统:

Configuration.UnitOfWork.RegisterFilter("PersonFilter", false);

第一个参数就是我们之前定义的名称,第二个参数指明默认情况下是否启用。在声明完这么一个可参数化过滤后,我们使用它,并在运行时给它值:

using (CurrentUnitOfWork.EnableFilter("PersonFilter"))
{
    using(CurrentUnitOfWork.SetFilterParameter("PersonFilter", "personId", 42))
    {
        var phones = _phoneRepository.GetAllList();
        //...
    }
}

我们应当从其它地方获取personId代替硬编码。上面是个可参数化过滤的例子,一个过滤可能有0或多个参数,如果没有参数,就没有必要设置过滤的参数值,同样,如果默认过滤是启用的,就不必再手动启用它(当然,我们可以禁用它)。

EntityFramework.DynamicFilters 文档

获取更多有关动态数据过滤信息,请参阅github页上的文档: https://github.com/jcachat/EntityFramework.DynamicFilters

我们可以为security, active/passive等实体自定义过滤。

 

其它 ORM

ABP数据过滤是为EntityFramework和NHibernate实现的,其它ORM上不可以用(包含EntityFramework Core)。但实质上,你可以在大多数情况上模仿它,只要你也是用仓储来获取数据的,你可以自定义一个仓储,然后重写GetAll和其它所需的数据获取方法。

 

posted @ 2016-10-27 01:19 kid1412 阅读(...) 评论(...) 编辑 收藏