jfinal网站开发模板做网站什么时候要用到虚拟主机

jfinal网站开发模板,做网站什么时候要用到虚拟主机,全国学校网站建设,鲤城区建设局网站1、 Association 的核心概念1.1、 什么是 Association#xff1f;定义#xff1a; Association 是 CDS 中一种声明性的语句#xff0c;用于定义两个 CDS 实体#xff08;视图或表#xff09;之间的关系。本质#xff1a; 它本身不是一条 JOIN 语句#xff0c;而是一个元…1、 Association 的核心概念1.1、 什么是 Association定义 Association 是 CDS 中一种声明性的语句用于定义两个 CDS 实体视图或表之间的关系。本质 它本身不是一条 JOIN 语句而是一个元数据定义描述了“如何连接”的关系。只有在被显式使用时例如通过路径表达式它才会在生成的 SQL 中触发实际的 JOIN 操作。1.2、 为什么需要 Association抽象性 将关系逻辑从查询中分离出来封装在模型内部提高复用性和可维护性。语义丰富 为数据模型赋予业务含义如“销售订单属于一个客户”。便捷性 通过简洁的路径表达式访问关联数据无需编写复杂的 JOIN。框架集成 是 SAP Fiori Elements 和 OData 服务自动提供导航功能的基础。1.3、 基本语法association[min..max] to TargetEntity as _Alias on $projection.SourceField _Alias.TargetField[min..max]基数定义关联的维度。[0..1] 目标实体最多有一条记录与之对应。[1..1] 目标实体必须有一条记录与之对应。[0..*]或[*] 目标实体有零条或多条记录与之对应。[1..*] 目标实体有一条或多条记录与之对应。TargetEntity 要关联的目标 CDS 视图或数据库表。_Alias 关联的别名通常以下划线_开头以区分于普通字段。on ... 关联条件类似于 JOIN 的 ON 子句。$projection代表当前视图的字段。2、Association 的用法与场景为了进行对比我们将使用以下简单的数据模型YBINV_CUSTOMER 客户主数据视图YBINV_ORDER 销售订单抬头视图2.1、Association定义与路径表达式目标 在订单抬头视图中关联到客户主数据以获取客户名称。2.1.1、定义 Association// 客户主数据视图 defineview YBINV_CUSTOMER asselect key kunnr, land1, name1 from kna1 // 销售订单头视图 defineview YBINV_ORDER asselect vbeln, auart, kunnr, _customer from vbak // 定义到客户的关联 association[1..1] to YBINV_CUSTOMER as _customer on $projection.kunnr _customer.kunnr关键点此处使用Association关联客户并定义了一个别名_customer。基数[1..1]表示每个订单必须对应一个客户。关联条件使用$projection引用vbak的字段。2.1.2、使用路径表达式消费 Association仅定义 Association 不会在结果中看到任何信息。必须在select列表中显式消费它。// 消费 Association 的视图 defineview YBINV_ORDER_CUSTOMER asselect vbeln, auart, kunnr, // 使用路径表达式将关联实体的字段“带”过来 _customer.name1, // 获取客户名称 _customer.land1 // 获取客户国家 from YBINV_ORDER生成的 SQL 等价于SELECT so.vbeln, so.auart, so.kunnr, cust.name1, cust.land1 FROM VBAK AS so LEFT OUTER JOIN KNA1 AS cust ON so.kunnr cust.kunnr执行结果2.2、内外连接基数只定义了表的关系但不影响最终生成的SQL连接。比如定义了association[1..1] to vbap as _item on $projection.vbeln _item.vbeln但是系统执行查询时仍然生成的是左连接因为系统默认采用left outer join 进行关联。如果要使用内连接INNER JOIN需要特殊处理。比如在查询时加入限制defineview YBINV_ORDER_CUSTOMER asselect vbeln, auart, kunnr, _item[inner].posnr, //强制使用inner连接 _item.kwmeng from YBINV_ORDER2.3、过滤 Association在消费时对 Association 指向的目标实体进行过滤。比如我们只想获取德国的客户信息。defineview YBINV_ORDER_CUSTOMER asselect vbeln, auart, kunnr, // 使用路径表达式将关联实体的字段“带”过来 _customer[land1 DE].name1, // 获取德国客户名称 _customer.land1 // 这个仍然是原始的客户国家 from YBINV_ORDER结果对比订单ID客户名称客户国家客户名称SO001ABCDEABCSO002XYZ CorpUSNULLSO003GermanDEGerman过滤只影响通过该路径表达式获取的值不会影响主结果集的行数也不会影响其他使用同一 Association 的路径。2.4、暴露 Association 用于导航在 OData 服务中我们经常希望将 Association 本身暴露为一个导航链接Navigation Link而不是直接展开其字段。在 OData 元数据中定义/YBINV_UI_CUSTOMER_CDS/YBINV_UI_CUSTOMER(SO001)/toCustomer这样的导航属性。OData.publish: true defineview YBINV_UI_CUSTOMER asselect key vbeln, auart, kunnr, // 直接暴露 Association而不是其字段 // 这将在 OData 元数据中生成一个名为 toCustomer 的导航属性 其中to是OData自动添加的导航前缀 _customer as Customer from YBINV_ORDER结果与对比不暴露 Association OData 服务只有平铺的字段如name1,land1。暴露 Association OData 服务包含一个导航链接。客户端可以通过以下方式访问关联数据GET /YBINV_UI_CUSTOMER(SO001)?$expandtoCustomerGET /YBINV_UI_CUSTOMER(SO001)/toCustomer404错误对于导航连接有时系统会自动添加前缀比如to所以如果访问报404错误需要看/$metadata文件中NavigationProperty NametoCustomer对应的name值。这种方式提供了更大的灵活性允许客户端决定是否需要以及何时需要加载关联数据。2.5、使用$projection进行自关联当关联条件依赖于当前视图中的计算字段或筛选后的结果时需要使用$projection。比如当客户为空时默认一个客户需要使用case when语法得出计算后的字段ZKUNNR然后通过ZKUNNR查询对应的客户主数据defineview YBINV_ORDER asselect key vbeln, auart, case when kunnr isnull then0000300022//如果没有客户就默认客户编码 else kunnr endas zkunnr, _customer, _item from vbak // 定义到客户的关联 此处使用处理过的字段关联 association [0..1] to YBINV_CUSTOMER as _customer on $projection.zkunnr _customer.kunnr$projection确保了关联条件是在当前视图的上下文包括可能的计算和过滤中进行的。3、JOIN和Association的对比通过以下几点对两种方法进行深度对比3.1、灵活性与过度获取数据JOIN 封装的问题// 基础视图已经固定返回所有客户字段 defineview I_SalesOrderHeaderWithCustomer asselectfrom snwd_so innerjoin snwd_bpa {...} { salesorder_id, gross_amount, customer_name, // 总是返回 customer_country, // 总是返回 customer_city, // 总是返回 customer_phone, // 总是返回 customer_email // 总是返回 };使用 Association 的灵活性defineview I_SalesOrderHeader asselectfrom snwd_so { key salesorder_id, gross_amount, currency_code, _customer from vbak // 定义到客户的关联 association[1..1] to I_Customer as _customer on $projection.customer_guid _Customer.customer_id // 消费视图1只需要客户名称 defineview ZC_SimpleOrder asselectfrom I_SalesOrderHeader { salesorder_id, gross_amount, _Customer.customer_name // 只获取需要的字段 }; // 消费视图2不需要客户信息 defineview ZC_FinancialReport asselectfrom I_SalesOrderHeader { salesorder_id, gross_amount, currency_code // 不消费 _Customer不会产生 JOIN //_Customer.customer_name };对比结果场景JOIN 封装Association只需要1个客户字段仍然获取所有客户字段只获取需要的字段不需要客户数据仍然执行 JOIN不执行 JOIN需要不同客户字段组合需要创建多个基础视图单一基础视图满足所有需求3.2、维护成本当客户模型变化时JOIN 封装方式// 客户表新增了重要字段 altertable snwd_bpa add company_size nvarchar(20); // 需要修改所有封装了JOIN的基础视图 defineview I_SalesOrderHeaderWithCustomer asselectfrom ... { ..., _customer.company_size // 必须手动添加 }; // 所有基于这个视图的消费视图都能看到新字段可能不需要Association 方式// 只需要在 YBINV_CUSTOMER视图中暴露新字段 defineview I_Customer asselectfrom snwd_bpa { ..., company_size // 在源头添加 }; // 消费视图按需决定是否使用新字段 // 不需要修改任何现有的消费视图3.3、多重关系处理复杂场景订单有创建者、修改者、销售员等多个人员关联JOIN 封装的困境defineview I_SalesOrderHeaderWithAllJoins asselectfrom snwd_so innerjoin snwd_bpa as _customer ... leftjoin snwd_emp as _creator ... leftjoin snwd_emp as _salesperson ... leftjoin snwd_bpa as _bill_to_party ... { salesorder_id, _customer.customer_name, _creator.employee_name as creator_name, _salesperson.employee_name as salesperson_name, _bill_to_party.formatted_name as bill_to_name // 字段爆炸命名冲突等风险 };Association 的清晰方案defineview I_SalesOrderHeader asselectfrom snwd_so { key salesorder_id, association [1..1] to I_Customer as _Customer ..., association [0..1] to I_Employee as _CreatedBy ..., association [0..1] to I_Employee as _SalesPerson ..., association [0..1] to I_Customer as _BillToParty ... }; // 消费时 按需选择 defineview ZC_OrderForSales asselectfrom I_SalesOrderHeader { salesorder_id, _Customer.customer_name, _SalesPerson.employee_name // 只关心销售相关 }; defineview ZC_OrderForBilling asselectfrom I_SalesOrderHeader { salesorder_id, _BillToParty.customer_name // 只关心账单相关 };3.4、框架集成与语义化Association 的独特优势3.4.1、OData 导航OData.publish: true defineview ZC_SalesOrderForOData asselectfrom I_SalesOrderHeader { key salesorder_id, gross_amount, _Customer as ToCustomer // 自动生成导航属性 };客户端可以调用/SalesOrders(123)/ToCustomer3.4.2、文本关联defineview YBINV_ORDER asselectfrom vbak // 定义到客户的关联 association [1..1] to YBINV_CUSTOMER as _customer on $projection.kunnr _customer.kunnr { key vbeln, auart, ObjectModel.text.element: [name] //绑定name和kunnr kunnr, Semantics.text: true _customer.name, //将name作为描述 _customer }在消费视图中定义OData.publish: true defineview YBINV_UI_CUSTOMER asselect key vbeln, auart, ObjectModel.text.association: _customer//在客户中展示描述 kunnr, _customer.name, _customer as Customer from YBINV_ORDERUI 自动显示客户名称3.4.3、搜索帮助Value Help注解Consumption.valueHelpDefinitiondefineview ZC_SalesOrder asselectfrom I_SalesOrderHeader { Consumption.valueHelpDefinition: [{ entity: { name: I_Customer, element: customer_guid } }] customer_guid, _Customer.customer_name };3.5、性能对比实际执行计划分析JOIN 封装视图消费时该视图已经执行了完整的JOIN。Association 视图消费时优化器可能将路径表达式重写为高效的JOIN只获取需要的字段。4、 总结与最佳实践特性传统 SQL JOINCDS Association本质命令式是查询的一部分声明式是模型元数据的一部分复用性差JOIN 逻辑在每个查询中重复极佳定义一次随处消费可读性复杂查询可读性差路径表达式使查询意图更清晰灵活性直接控制 JOIN 类型和条件通过基数和过滤间接控制更抽象框架集成无特殊支持深度集成是 Fiori Elements 和 OData 导航的基石耦合查询与关系逻辑紧耦合查询与关系逻辑解耦模型更清晰最佳实践始终使用 Association 在新的 CDS 开发中优先使用 Association 而不是直接 JOIN。明确的别名 使用下划线_开头为 Association 命名以示区分。用于文本关联 结合ObjectModel.text.association注解自动为代码字段提供描述文本。OData 导航 通过暴露 Association 来构建丰富的、可导航的 OData 服务。以上就是关于Association的介绍希望对你有所帮助