Foxnic-SQL (16) ——Foxnic-SQL的模型关联方法

LeeFJ
• 阅读 367
Foxnic-SQL (16) ——Foxnic-SQL的模型关联方法
概述

  本节我们将用一个简单的例子,来说明对象之间的关联关系,以及 Foxnic-SQL 是如何处理这种关联关系的。首先,我们引入商城下单的简单业务模型,这个模型里面包括了商品、订单、订单明细以及收件人地址,这个模型足够简单,所以很容易分析出他们之间的关联关系。

  本文中的示例代码均可在 https://gitee.com/LeeFJ/foxnic-samples 项目中找到。

业务分析

  从下面这个ER图,我们可以看到四个表,订单(example_order)、订单明细(example_order_item)、商品(example_goods)、收件地址(example_address),如果按常规逻辑,我们从订单开始入手,一个订单包含若干商品,并投第到一个地址上。

  不难分析出他们之间的关系:一个订单只会有一个地址,所以他们是一对一的;把这个关系反一下,同一个地址可能会收到多个订单,所以他们是一对多的关系;通常来讲,订单和商品是属于多对多关系,因为一个商品可以属于不同的订单,一个订单也可以包含多个商品;同理可以推得,地址和商品也是多对多的关系。但是这样的关系分析似乎有点搞脑子。

Foxnic-SQL (16) ——Foxnic-SQL的模型关联方法

  Foxnic-SQL 将这种进行简化,只有一对一或一对多两种关系。即,如果我们将上述的四个表转换为实体类,当某一个类要持有对方时,它要为对方设置单一属性还是 List 属性来判断两者关系。

  例如 Order 类要持有 Address 类时,它只需要定义一个属性 private Address address; 就可以了,这是 Order 对于 Address 就是一对一的关系;再如,Order 类要持有 Goods 则需要为其定义一个列表 private List goodsList; 才可以,这时Order 对于 Goods 就是一对多的关系。

  Foxnic-SQL 要求尽可能分析清楚这些实体之间的关系,并配置到系统中,最终形成一个实体关系的大地图,当我们定义清楚A持有B所需要的属性类型,我们同时也就是构建了一个全局的对象模型,如图所示:

Foxnic-SQL (16) ——Foxnic-SQL的模型关联方法

  下面,我们用下单的这个例子,来系统说明 Foxnic-SQL 是如何完成关系搭建与模型的 Join。

生成表结构元数据

  要使表之间的关系可以在 Java 代码中可配置,那就必须可以在 Java 代码中可以引用到表。所以,第一步的工作就是将数据表对象化,Foxnic-SQL 的代码生成模块已经实现了这部分工作,我只要做一些简单的配置即可完成调用生成 Java 形式的表结构,代码如下:

package com.leefj.foxnic.sql.demo.generator;

import com.github.foxnic.dao.spec.DAO;
import com.github.foxnic.generator.builder.constants.DBMetaClassFile;
import com.leefj.foxnic.sql.demo.config.DBInstance;

public class ExampleDBMetaGenerator {
    /**
* 运行main函数生成代码
* */
    public static void main(String[] args) throws Exception {
        ExampleDBMetaGenerator g = new ExampleDBMetaGenerator();
        g.buildDBMeta();
    }
    /**
* 生成DBMeta数据
* */
    private void buildDBMeta() {
        // 初始化 DAO 对象
        DAO dao= DBInstance.DEFAULT.dao();
        // 初始化全局设置
        GeneratorUtil.initGlobalSettings();
        // 初始化 DBMetaClassFile 构建器
        DBMetaClassFile dbMetaBuilder=new DBMetaClassFile(dao,GeneratorUtil.getProject(), "com.leefj.foxnic.sql.demo.config","ExampleTables");
        // 过滤与排除不需要的表
        dbMetaBuilder.setTableFilter(table->{
            table=table.toLowerCase();
            // 仅生成以 example_ 开头的表
            if(table.startsWith("example_")) return true;
            return false;
        });
        // 保存为 Java 代码
        dbMetaBuilder.save(true);
    }
}

  运行 main 函数,将生成 com.leefj.foxnic.sql.demo.config.db.ExampleTables 类,这个类包含了相关业务表的表结构信息。由于代码较多此处不做展示,可签出完整项目 https://gitee.com/LeeFJ/foxnic-samples 查看。

生成基础实体

  所谓生成基础实体就是完全按照表结构生成实体类,每个表按默认的命名转换器生成实体,对应的表字段则生成相应的类的成员属性。

package com.leefj.foxnic.sql.demo.generator;

import com.github.foxnic.commons.project.maven.MavenProject;
import com.github.foxnic.dao.spec.DAO;
import com.github.foxnic.generator.builder.model.PoClassFile;
import com.github.foxnic.generator.config.ModuleContext;
import com.github.foxnic.sql.meta.DBTable;
import com.leefj.foxnic.sql.demo.config.DBInstance;
import com.leefj.foxnic.sql.demo.config.db.ExampleTables;

/**
* 实体类生成器
* */
public class EntityGenerator {
    public static interface  Config  {
        void config(PoClassFile poType);
    }

    private static final String BASE_PACKAGE = "com.leefj.foxnic.sql.demo.app";

    /**
* 需要首先运行 ExampleDBMetaGenerator 生成 ExampleTables 类
* */
    public static void main(String[] args) {
        EntityGenerator generator = new EntityGenerator();
        // 生成商品实体类
        generator.generate(ExampleTables.EXAMPLE_GOODS.$TABLE);
        // 生成订单实体类
        generator.generate(ExampleTables.EXAMPLE_ORDER.$TABLE);
        // 生成订单明细实体类
        generator.generate(ExampleTables.EXAMPLE_ORDER_ITEM.$TABLE);
        // 生成地址实体类
        generator.generate(ExampleTables.EXAMPLE_ADDRESS.$TABLE);
    }
    /**
    * 按表生成
    * */
    public void generate(DBTable table) {
        generate(table,null);
    }
    /**
    * 按表生成
    * */
    public void generate(DBTable table,Config config) {
        DAO dao = DBInstance.DEFAULT.dao();
        MavenProject project = GeneratorUtil.getProject();
        String pkg = table.name().split("_")[0];
        String prefix = pkg + "_";
        ModuleContext context = new ModuleContext(GeneratorUtil.initGlobalSettings(),table,prefix,BASE_PACKAGE + "." + pkg);
        context.setDomainProject(project);
        context.setServiceProject(project);
        context.setDAO(dao);
        if(config!=null) {
            config.config(context.getPoClassFile());
        }
        context.buildPo();
        context.buildVo();
        context.buildService();
    }
}

  运行 main 方法将生成实体类代码,以上代码生成 PO、VO 对象以及这些类型对应的元数据类型,代码生成后如图所示:

Foxnic-SQL (16) ——Foxnic-SQL的模型关联方法

加入扩展属性

  下面我们要为这些实体类加入扩展属性,正如我们刚刚在上文中分析的那样,Order 类要持有 Address 类时,需要定义一个属性 private Address address; Order 类要持有 Goods 则需要为其定义一个列表 private List goodsList; 才可以。我们修改上一步中的 EntityGenerator 类,调整 main 方法如下:

/**
* 需要首先运行 ExampleDBMetaGenerator 生成 ExampleTables 类
* */
public static void main(String[] args) {
    EntityGenerator generator = new EntityGenerator();
    // 生成商品实体类
    generator.generate(ExampleTables.EXAMPLE_GOODS.$TABLE, poType -> {
        // Goods 对象 通过 orderList 属性持有 Order
        poType.addListProperty(Goods.class,"orderList","订单明细商品","订单明细商品");
        // Goods 对象 通过 addressList 属性持有 Address
        poType.addListProperty(Address.class,"addressList","收件地址","收件地址,包括收件人以及手机号码");
        // Goods 对象 通过 itemList 属性持有 OrderItem
        poType.addListProperty(OrderItem.class,"itemList","订单明细","订单明细");
    });
    // 生成订单实体类
    generator.generate(ExampleTables.EXAMPLE_ORDER.$TABLE , poType -> {
        // Order 对象 通过 goodsList 属性持有 Goods
        poType.addListProperty(Goods.class,"goodsList","订单明细商品","订单明细商品");
        // Order 对象 通过 address 属性持有 Address
        poType.addSimpleProperty(Address.class,"address","收件地址","收件地址,包括收件人以及手机号码");
        // Order 对象 通过 itemList 属性持有 OrderItem
        poType.addListProperty(OrderItem.class,"itemList","订单明细","订单明细");
    });
    // 生成订单明细实体类
    generator.generate(ExampleTables.EXAMPLE_ORDER_ITEM.$TABLE, poType -> {
        // OrderItem 对象 通过 goodsList 属性持有 Goods
        poType.addSimpleProperty(Goods.class,"goods","订单明细商品","订单明细商品");
        // OrderItem 对象 通过 address 属性持有 Address
        poType.addSimpleProperty(Address.class,"address","收件地址","收件地址,包括收件人以及手机号码");
        // OrderItem 对象 通过 order 属性持有 Order
        poType.addListProperty(Order.class,"order","订单","订单");
    });
    // 生成地址实体类
    generator.generate(ExampleTables.EXAMPLE_ADDRESS.$TABLE, poType -> {
        // Address 对象 通过 goodsList属性 持有 Goods
        poType.addListProperty(Goods.class,"goodsList","订单明细商品","订单明细商品");
        // Address 对象 通过 orderList 持有 Order
        poType.addListProperty(Address.class,"orderList","收件地址","收件地址,包括收件人以及手机号码");
        // Address 对象 通过 itemList 持有 OrderItem
        poType.addListProperty(OrderItem.class,"itemList","订单明细","订单明细");
    });
}

  通过上面的代码,我们定义了任意对象如果要持有对方时需要定义的属性。当然,这些定义的属性中有部分没有实际的业务意义,我没这里仅仅是从技术角度来说明对象之间关联属性的定义方法。再次运行

  注意,代码生成并非只是本文中展示的一种范式,小伙伴们可按需要自行实现。

配置关联关系

  前面的步骤,我们生成了实体类以及实体类的扩展属性,有了扩展属性后我们要为这些扩展属性配置好关联关系。关联关系在 ExampleRelationManager 类中配置,如下代码所示:

import com.github.foxnic.dao.relation.RelationManager;
import com.leefj.foxnic.sql.demo.app.domain.example.meta.AddressMeta;
import com.leefj.foxnic.sql.demo.app.domain.example.meta.GoodsMeta;
import com.leefj.foxnic.sql.demo.app.domain.example.meta.OrderItemMeta;
import com.leefj.foxnic.sql.demo.app.domain.example.meta.OrderMeta;
import com.leefj.foxnic.sql.demo.config.db.ExampleTables;

public class ExampleRelationManager extends RelationManager {

    @Override
    protected void config() {
        this.setupOrder();
    }

    public void setupOrder() {
        // 以下是 Order 扩展属性的关联关系配置
        // Order.address 属性通过 EXAMPLE_ORDER.ADDRESS_ID 字段关联到 EXAMPLE_ADDRESS.ID 字段
        this.property(OrderMeta.ADDRESS_PROP)
            .using(ExampleTables.EXAMPLE_ORDER.ADDRESS_ID).join(ExampleTables.EXAMPLE_ADDRESS.ID)
            // 由于订单地址不常变动,可以开启缓存
            .cache(true);

        // Order.goodsList 属性通过 EXAMPLE_ORDER.ID 字段关联到 EXAMPLE_ORDER_ITEM.ORDER_ID 字段
        // 再通过 EXAMPLE_ORDER_ITEM.GOODS_ID 字段关联到 EXAMPLE_GOODS.ID 字段
        this.property(OrderMeta.GOODS_LIST_PROP)
            .using(ExampleTables.EXAMPLE_ORDER.ID).join(ExampleTables.EXAMPLE_ORDER_ITEM.ORDER_ID)
            .using(ExampleTables.EXAMPLE_ORDER_ITEM.GOODS_ID).join(ExampleTables.EXAMPLE_GOODS.ID)
            // 订单一旦生成,订单明细不再变动,开启缓存
            .cache(true);

        // Order.itemList 属性通过 EXAMPLE_ORDER.ID 字段关联到 EXAMPLE_ORDER_ITEM.ORDER_ID 字段
        this.property(OrderMeta.ITEM_LIST_PROP)
            .using(ExampleTables.EXAMPLE_ORDER.ID).join(ExampleTables.EXAMPLE_ORDER_ITEM.ORDER_ID)
            .cache(true);

        // 以下是 OrderItem 扩展属性的关联关系配置
        // OrderItem.order 属性通过 EXAMPLE_ORDER_ITEM.ORDER_ID 字段关联到 EXAMPLE_ORDER.ID 字段
        this.property(OrderItemMeta.ORDER_PROP)
            .using(ExampleTables.EXAMPLE_ORDER_ITEM.ORDER_ID).join(ExampleTables.EXAMPLE_ORDER.ID)
            .cache(true);

        // OrderItem.goods 属性通过 EXAMPLE_ORDER_ITEM.GOODS_ID 字段关联到 EXAMPLE_GOODS.ID 字段
        this.property(OrderItemMeta.GOODS_PROP)
            .using(ExampleTables.EXAMPLE_ORDER_ITEM.GOODS_ID).join(ExampleTables.EXAMPLE_GOODS.ID)
            .cache(true);


        // 以下是 Goods 扩展属性的关联关系配置
        this.property(GoodsMeta.ORDER_LIST_PROP)
            .using(ExampleTables.EXAMPLE_GOODS.ID).join(ExampleTables.EXAMPLE_ORDER_ITEM.GOODS_ID)
            .using(ExampleTables.EXAMPLE_ORDER_ITEM.ORDER_ID).join(ExampleTables.EXAMPLE_ORDER.ID)
            .cache(true);

        this.property(GoodsMeta.ADDRESS_LIST_PROP)
            .using(ExampleTables.EXAMPLE_GOODS.ID).join(ExampleTables.EXAMPLE_ORDER_ITEM.GOODS_ID)
            .using(ExampleTables.EXAMPLE_ORDER_ITEM.ORDER_ID).join(ExampleTables.EXAMPLE_ORDER.ID)
            .using(ExampleTables.EXAMPLE_ORDER.ADDRESS_ID).join(ExampleTables.EXAMPLE_ADDRESS.ID)
            .cache(true);

        this.property(GoodsMeta.ITEM_LIST_PROP)
            .using(ExampleTables.EXAMPLE_GOODS.ID).join(ExampleTables.EXAMPLE_ORDER_ITEM.GOODS_ID)
            .cache(true);

        // 以下是 Address 扩展属性的关联关系配置
        this.property(AddressMeta.ORDER_LIST_PROP)
            .using(ExampleTables.EXAMPLE_ADDRESS.ID).join(ExampleTables.EXAMPLE_ORDER.ADDRESS_ID)
            .cache(true);

        this.property(AddressMeta.ITEM_LIST_PROP)
            .using(ExampleTables.EXAMPLE_ADDRESS.ID).join(ExampleTables.EXAMPLE_ORDER.ADDRESS_ID)
            .using(ExampleTables.EXAMPLE_ORDER.ID).join(ExampleTables.EXAMPLE_ORDER_ITEM.ORDER_ID)
            .cache(true);

        this.property(AddressMeta.GOODS_LIST_PROP)
            .using(ExampleTables.EXAMPLE_ADDRESS.ID).join(ExampleTables.EXAMPLE_ORDER.ADDRESS_ID)
            .using(ExampleTables.EXAMPLE_ORDER.ID).join(ExampleTables.EXAMPLE_ORDER_ITEM.ORDER_ID)
            .using(ExampleTables.EXAMPLE_ORDER_ITEM.GOODS_ID).join(ExampleTables.EXAMPLE_GOODS.ID)
            .cache(true);
    }
}

  同样,我们在关系配置中几乎配置了所有的两两关系,当然某些关系并没有业务意义,仅做技术展示。关系配置时还可以有其它更多的控制,例如额外的条件、排序等,请小伙伴们自行探索。

通过Service拉取模型

  通过之前的代码生成,不仅生成的PO、VO类,同时也生成了 Service 类,通过 DBInstance 可以拿到这个 Service 对象,若是在 Web 环境下,直接使用 Spring 的依赖注入即可拿到 Service 对象。通过 Service 拉取模型的示例代码如下:

/**
* 通过 Service 的 Join 方法完成属性数据的填充操作
* */
@Test
public void demo_1() {
    // 获得 Service
    IOrderService orderService=DBInstance.DEFAULT.getService(OrderServiceImpl.class);
    // 查询所有订单
    List<Order> orders= orderService.queryList(new Order());
    // 填充订单属性
    orderService.join(orders, OrderMeta.ADDRESS,OrderMeta.ITEM_LIST,OrderMeta.GOODS_LIST);
    // 输出填属性填充后的订单列表
    System.out.println(JSONUtil.format(JSONUtil.toJSONArray(orders)));
}

  以上代码首先查询了订单列表,此时获得的订单列表并未填充扩展属性值,在调用 Service 的 join 方法,指定需要 Join 的属性名称即可。

  Service 的 join 方法事实上是间接调用了 DAO 的 join 方法,本例中 join 了三个属性,这三个属性的查询与 join 过程并非顺序执行的,而是利用了 java 的 fork...join 框架进行了并行操作。join 过程中会有一个输出,如下所示:

JOIN(DATA) FORK(21):128 , el=7 >>>

Order :: List goodsList , properties : id , route example_order to example_goods

example_order_item( goods_id ) = example_goods( id )

  第一行的 JOIN(DATA) 是指当前的 join 操作是数据操作,另外还有一种 JOIN(SEARCH),在数据搜索时用到,吗这里不做展开。FORK(21):128,其中 21 是指线程ID,128 是指 fork 时拆分的行数。这里是指如果 orders 的元素个数超过128,那么就按128的规格进行 frok 任务拆解。 el=7 是指当前 orders 实际数量是7个。

  Order :: List goodsList 是指当前正在处理 Order 类的 goodsList 属性, properties : id 是指关联的起始属性是 Order.id , route example_order to example_goods 是指从 example_order 表路由到 example_goods 表。example_order_item( goods_id ) = example_goods( id ) 展示了本次 join 的关联关系。这些关联关系我们在 ExampleRelationManager 类里做了配置。

  最后,我们可以在 SQL 日志上看到 join 最终执行的SQL语句:

┏━━━━━ SQL [ SELECT t_0.* , t_1.order_id join_f0 , t_0.id join_fs_example_goods_sf_nioj_id ... ] ━━━━━

┣ 语句:SELECT t_0.* , t_1.order_id join_f0 , t_0.id join_fs_example_goods_sf_nioj_id , t_0.id pk_join_fs_example_goods_sf_nioj_id , t_1.goods_id join_fs_example_order_item_sf_nioj_goods_id , t_1.order_id join_fs_example_order_item_sf_nioj_order_id , t_1.id pk_join_fs_example_order_item_sf_nioj_id FROM (select * from example_goods WHERE ( deleted= ? ) ) t_0

join (select * from example_order_item WHERE ( deleted= ? ) ) t_1 on t_1.goods_id = t_0.id

WHERE t_1.order_id IN ( ? , ? , ? , ? , ? , ? , ? ) AND t_1.deleted= ?

┣ 参数:{"PARAM_1":0,"PARAM_9":"651345265944428544","PARAM_8":"651017423926853632","PARAM_10":0,"PARAM_7":"583188757629370368","PARAM_6":"651024562955223040","PARAM_5":"651017546694131712","PARAM_4":"583028022102200320","PARAM_3":"651024388312793088","PARAM_2":0}

┣ 执行:SELECT t_0.* , t_1.order_id join_f0 , t_0.id join_fs_example_goods_sf_nioj_id , t_0.id pk_join_fs_example_goods_sf_nioj_id , t_1.goods_id join_fs_example_order_item_sf_nioj_goods_id , t_1.order_id join_fs_example_order_item_sf_nioj_order_id , t_1.id pk_join_fs_example_order_item_sf_nioj_id FROM (select * from example_goods WHERE ( deleted= 0 ) ) t_0

join (select * from example_order_item WHERE ( deleted= 0 ) ) t_1 on t_1.goods_id = t_0.id

WHERE t_1.order_id IN ( '651024388312793088' , '583028022102200320' , '651017546694131712' , '651024562955223040' , '583188757629370368' , '651017423926853632' , '651345265944428544' ) AND t_1.deleted= 0

┣ 结果:

┣━ 耗时:84ms , start = 1672796438302

┣━ 返回:RcdSet,size=2

┣ TID:null

┗━━━━━ SQL [ SELECT t_0.* , t_1.order_id join_f0 , t_0.id join_fs_example_goods_sf_nioj_id ... ] ━━━━━

通过DAO拉取模型

  DAO 本身也有 join 方法,用法和 Service 的 join 方法相似,这里不做展开。本例中,我们使用 DAO 的 fill...with 方法拉取模型。

/**
* 通过 DAO 对象的 fill...with 方法完成属性数据的填充
* */
@Test
public void demo_2() {
    // 获得 Service
    IOrderService orderService=DBInstance.DEFAULT.getService(OrderServiceImpl.class);
    // 查询所有订单
    List<Order> orders= orderService.queryList(new Order());
    DAO dao=orderService.dao();
    // 通过 dao 的 fill 方法填充 orders 列表里面元素的扩展属性
    dao.fill(orders)
        // 填充 orders 里面每个元素的 address 属性
        .with(OrderMeta.ADDRESS)
        // 填充 orders 里面每个元素的 itemList 属性
        .with(OrderMeta.ITEM_LIST)
        // 填充 orders 里面每个元素的 goodsList 属性
        .with(OrderMeta.GOODS_LIST)
        // 执行最终的 join 操作
        .execute();
    // 输出填属性填充后的订单列表
    System.out.println(JSONUtil.format(JSONUtil.toJSONArray(orders)));
}

  通过还可以进一步拉取级联模型:

/**
* 通过 DAO 对象的 fill...with 方法完成属性数据的级联填充
* */
@Test
public void demo_3() {
    // 获得 Service
    IOrderService orderService=DBInstance.DEFAULT.getService(OrderServiceImpl.class);
    // 查询所有订单
    List<Order> orders= orderService.queryList(new Order());
    DAO dao=orderService.dao();
    // 通过 dao 的 fill 方法填充 orders 列表里面元素的扩展属性
    dao.fill(orders)
        // 填充 orders 里面每个元素的 address 属性,并填充  address 属性的 orderList 属性
        .with(OrderMeta.ADDRESS,AddressMeta.ORDER_LIST)
        // 填充 orders 里面每个元素的 address 属性,并填充  address 属性的 goodsList 属性
        .with(OrderMeta.ADDRESS,AddressMeta.GOODS_LIST)
        // 填充 orders 里面每个元素的 itemList 属性
        .with(OrderMeta.ITEM_LIST)
              // 填充 orders 里面每个元素的 goodsList 属性
          .with(OrderMeta.GOODS_LIST)
        // 执行最终的 join 操作
        .execute();
    // 输出填属性填充后的订单列表
    System.out.println(JSONUtil.format(JSONUtil.toJSONArray(orders)));
}
刻画模型

  通过上面的两个示例,我们注意到,我们在拉取对象时,并未指定字段,这样就会拉出多余的字段,为了精确刻画需要拉取的模型字段,我们可以为 fill...with 指定 fields , 如下代码所示:

/**
* 通过 DAO 对象的 fill...with 方法完成属性数据的填充,并用 fields 指定查询字段
* */
@Test
public void demo_4() {
    // 获得 Service
    IOrderService orderService=DBInstance.DEFAULT.getService(OrderServiceImpl.class);
    // 查询所有订单
    List<Order> orders= orderService.queryList(new Order());
    DAO dao=orderService.dao();
    // 构建 Order 对象需要查询的字段
    FieldsBuilder orderFields=FieldsBuilder.build(dao, ExampleTables.EXAMPLE_ORDER.$TABLE);
    orderFields.addAll().removeDBTreatyFields();
    // 构建 address 对象需要的字段
    FieldsBuilder addressFields=FieldsBuilder.build(dao, ExampleTables.EXAMPLE_ADDRESS.$TABLE);
    addressFields.addAll().removeDBTreatyFields();
    // 通过 dao 的 fill 方法填充 orders 列表里面元素的扩展属性
    dao.fill(orders)
        // 填充 orders 里面每个元素的 address 属性
        .with(OrderMeta.ADDRESS)
        // 填充 orders 里面每个元素的 itemList 属性
        .with(OrderMeta.ITEM_LIST)
        // 填充 orders 里面每个元素的 goodsList 属性
        .with(OrderMeta.GOODS_LIST)
        // 指定字段
        .fields(orderFields,addressFields)
        // 执行最终的 join 操作
        .execute();
    // 输出填属性填充后的订单列表
    System.out.println(JSONUtil.format(JSONUtil.toJSONArray(orders)));
}
模型装配的原则

  从整个示例的过程,大家注意到,示例中的绝大多是代码是生成的,在代码生成的基础上,我们配置两个对象之间的引用关系和关联关系。

  Foxnic-SQL 的模型构建过程是按需拉取的,不同接口需要不同的数据,开发人员通过 Service 的 join 方法或 DAO 的 fill...with 方法手动指定本次要拉取的属性范围,使拉取过程更加符合接口要求。

  事实上,引用关系和关联关系在一个系统中一般都是固定的,唯一不同的是在不同的场合拉取模型的范围,这个由开发人员控制,更加灵活方便。

小结

  本节主要介绍了在 Foxni-SQL 中使用 join 方法填充对象模型。基本步骤包括,生成数据库表元数据、生成 PO、VO、Service 代码、配置关联关系、使用 Service 或 DAO 完成模型装配。

相关项目

  https://gitee.com/LeeFJ/foxnic

  https://gitee.com/LeeFJ/foxnic-web

  https://gitee.com/lank/eam

  https://gitee.com/LeeFJ/foxnic-samples

官方文档

  http://foxnicweb.com/docs/doc.html

点赞
收藏
评论区
推荐文章
Wesley13 Wesley13
3年前
C语言
大家晚上好,最近忙每天忙于项目没有时间更新自己的博客,时间就是海绵嘛硬挤挤就是有的,咂看标题"流程图",编程界的一个不可或缺的技能,特别是在做复杂的逻辑的时候要处理好每一步的关系,在数据中讲就是数据之间的关联关系,或者关联模型等,通俗点也就是父子,母子等关系。首先给大家介绍几款画流程图的软件:亿图图示,VISIO,百度脑图(在线使用),office等
Stella981 Stella981
3年前
Django之ORM(多对多)
一、ManyToManyField1、classRelatedManager"关联管理器"是在一对多或者多对多的关联上下文中使用的管理器。它存在于下面两种情况:1.外键关系的反向查询2.多对多关联关系简单来说就是当 点后面的对象 可能存在多个的时
Stella981 Stella981
3年前
Python 常用的ORM框架简介
ORM概念ORM(ObjectRalationalMapping,对象关系映射)用来把对象模型表示的对象映射到基于SQL的关系模型数据库结构中去。这样,我们在具体的操作实体对象的时候,就不需要再去和复杂的SQL语句打交道,只需简单的操作实体对象的属性和方法。ORM技术是在对象和关系之间提供了一条桥梁,前台的对象型数据和数据
Stella981 Stella981
3年前
Ruby on Rails,一对多关联(One
在上一篇文章中,我们知道通过has\_one和belongs\_to方法定义一对一关联关系。接下来是更常见的情况,一对多关联。比如老师与所教课程的关系,一个老师负责多个课程。换成对象之间的关系就是:一个老师hasmay课程,课程belongsto老师。!(http://img.my.csdn.net/uploads/201212/02/13
Wesley13 Wesley13
3年前
HQL的多表查询
对象之间总是有各种各样的关系,关联关系是类之间最常见的关系。多表查询是HQL中的强大功能之一,包括内连接、左连接和右连接等。多表查询的设置及运行都比较麻烦,在运行本节中的示例时,务必保证每一步都没有错误。 6.4.1 表之间的关联关系 在数据库joblog中用到了3个表:student(学生表)、course(课程表
Stella981 Stella981
3年前
Hibernate利用关联关系操纵对象
Hibernate利用关联关系操纵对象数据对象之间关联关系有一对一、一对多及多对多关联关系。在数据库操作中,数据对象之间的关联关系使用JDBC处理很困难。本节讲解如何在Hibernate中处理这些对象之间的关联关系。本节使用到4个类,它们分别是Student(学生)、Card(学生证)、Group(班级)和Cou
Stella981 Stella981
3年前
GraphX 在图数据库 Nebula Graph 的图计算实践
不同来源的异构数据间存在着千丝万缕的关联,这种数据之间隐藏的关联关系和网络结构特性对于数据分析至关重要,图计算就是以图作为数据模型来表达问题并予以解决的过程。!图计算实践(https://wwwcdn.nebulagraph.com.cn/nebulablog/practicegraphxnebulagraphalgorithm.png
Wesley13 Wesley13
3年前
3 OneToMany ManyToMany MappedBy Cascade
1双向1N关联对于1N关联,Hibernate推荐使用双向关联,而且不要让1的一方控制关联关系,而使用多的一方控制关联关系。a.一的一方 表示班级@Entity@Table(name"team_1")publicclassTeam{@Id@Gen
Stella981 Stella981
3年前
Hibernate 单向的一对多关联映射
单向的一对多关联关系(OnetoMany)对象模型关系分析:少的一端:会通过引用一个多端的集合对象,建立对象模型关系多的一端:没有任何变化,不知道和少的一端存在着关系。关系模型分析:少的一端:没有任何变化多的一端:会和少的一端建立外键关系使用时需要少的一端所对应的XXX.hbm.xml中进行配置<bagname"对多的
Wesley13 Wesley13
3年前
ThinkPHP 根据关联数据查询 hasWhere 的使用实例
很多时候,模型关联后需要根据关联的模型做查询。场景:广告表(ad),广告类型表(ad\_type),现在需要筛选出广告类型表中id字段为1且广告表中status为1的列表先看关联的设置部分 publicfunctionadType(){return$thisbelongsTo('A