基于星型结构业务模型的动态搜索框架的制作方法
基于星型结构业务模型的动态搜索框架的制作方法
【技术领域】：
[0001] 本发明设计了一种标准高效的动态搜索框架，其思想是：利用通用结构模型的数 据统一化处理特点，克服普通搜索技术和业务场景密切绑定的问题，克服普通搜索技术在 不同的业务场景下，开发维护量大，且工程量随着用户搜索条件的增加而急剧增大的问题。 使用本搜索框架，在实际应用中，只需少量的配置，实现了多种不同业务场景下，数据搜索 统一模式实现的问题，降低了开发、维护和后期扩展的工作量。
[0002] 本动态搜索框架的核心是一种基于星型结构的通用数据模型，我们称为"服务实 体（ServiceEntity) "。通过星型的数据结构来描述不同的业务逻辑，使得模型的结构实现 了统一化，并且提供了相关框架实现了数据的统一化处理。在此基础上发明了快速搜索框 架，在不同的搜索业务场景中，只需要做简单的配置，搜索框架根据简单的配置和统一化数 据框架，自动获取足够的搜索业务场景信息，并且根据用户实际输入，动态生成各种复杂的 SQL查询语句，实现多样化的业务场景下，搜索功能的统一模式实现。
【背景技术】：
[0003] 当前页面数据搜索普遍采用的技术：由于商务软件的实际应用场景千差万别，搜 索数据面临的应用场景也千差万别，目前没有固定的前台数据搜索技术来优化工作模式， 普遍采用的搜索技术都具有"零时性"的特点：一般在实际中采用手动设计的方式：根据前 台的输入数据，事先预测好各种可能的搜索条件，设置好各种场景用到的SQL语句，根据用 户在前台的输入，后台判断条件，决定采用哪些的SQL语句。
[0004] 目前搜索技术面临的问题：
[0005] 灵活性差：各种搜索的SQL语句在事先定义好，实际上将搜索过程和具体的场景 密切绑定在一起，必须事先根据可能的搜索情况定义好所有可能的SQL语句，工作量大，前 台能够接受的搜索条件比较有限。目前大部分软件在搜索视图中，能够提供的搜索条件比 较有限，特别是搜索字段对应后台多张数据库表，且前台对应的搜索条件很多，实现起来难 度很大。
[0006] 扩展型差：当在前台增加搜索条件时，所有预先定义的SQL语句可能都会改动。特 别是当后台涉及的表有变化时，增加表或者减少表，不仅所有的SQL语句会重新设计，因为 搜索条件变了，而且搜索场景也需要重新定义。
[0007] 通用性差：在不同的使用场景中，可能需要全部重新设计搜索逻辑。
[0008] 这样造成的后果是：目前大部分软件出于开发量和后期维护的考虑，在用户界面 上只能提供少量的查询条件，比如十个以内，当用户界面上提供的查询条件变多了后，特别 是查询条件涉及到后台多张表联合查询时，工作量会大大增加。从使用者角度上说，商务软 件只要在提供列表视图的页面上，都应该提供丰富的查询功能，才能使得用户能灵活高效 地发挥列表视图的特点。但是通过调查发现，目前大量的商务软件，提供的查询功能都比较 有限，不能做到随时随地，任何形式的数据都提供的查询功能，大部分软件都将查询功能单 独列举出来，只提供有限的查询功能，且只开放给比较核心的数据。
[0009] 星型结构的通用业务模型简介：领域驱动开发模式的提出，使得传统的面向对象 的软件开发中引入了各个部门都能使用，能交流的统一领域模型，使得软件开发更加面向 实际业务需求。但是，在没有统一的业务模型支持的框架下，实际的开发模型普遍是贫血的 JAVA基本数据类（JAVAP0J0类），开发模型和业务模型有不小的区别，需要花费大量精力 实现两种模型的转换；另一方面，实际的业务模型结构是千差万别的，在不同的业务场景， 需要不同的方法来处理不同的业务模型，增加了开发和维护的难度。基于星型结构的通用 业务模型，采用了通用的结构来描述不同场景的业务模型，一方面，使得开发模型和领域模 型实现了合并，直接通过领域模型实现建模，体现而来领域驱动建模ODD)的思想，同时， 统一化的模型使得数据的处理和维护变得简化，进一步使得统一框架来实现数据处理成为 可能。
[0010] 本发明设计了一种基于星型结构的数据模型上的动态搜索框架，该框架实现了搜 索过程和具体的业务场景隔离，具体业务场景由配置信息和统一数据框架提供，在实际应 用中，进行一些简单的配置后，可以自适应实现多种情况下的搜索，框架会根据前台视图模 型传入的搜索参数，自动生成搜索条件，自动找到所有应用到的数据库表，并动态生成各种 场景下的SQL语句，进行搜索。
[0011] 和传统的搜索技术相比，开发的工作量大大减少，维护的工作也大大减少，如果场 景发生变化，不管是变更视图模型的字段或者变更后台搜索的表，只需要调整搜索配置参 数就可以，杜绝了普通搜索技术由于涉及到的搜索字段和后台数据库表增加而开发量，维 护量成几何增加的问题。
【发明内容】
：
[0012] 本动态搜索框架的下，搜索的实现过程大致为：首先生成搜索场景配置信息、，配 置信息生成由两个阶段构成："静态配置"和"动态配置"，"静态配置"需要开发人员在开发 过程中手动配置，"动态配置"是指在实际运行过程中，根据统一化数据框架和用户输入的 搜索信息，动态生成。然后框架根据完整的配置信息生成"逻辑关系路径"，每条路径由唯一 的"起始节点"出发，根据一系列关联条件，直到最后一个节点为止。再然后，基于"搜索逻 辑路径"，生成SQL语句的搜索条件，并且再次合并路径，直到生成最终的搜索SQL语句。最 后步骤是系统执行搜索命令，并返回搜索结果。
[0013]如前面所述：搜索的实现实现过程可以分为五个阶段：1.静态配置，2.动态配置， 3.动态生成逻辑关系路径，4.生成SQL搜索语句，5执行搜索。前面两个步骤都是为搜索框 架提供完整的搜索配置信息。为了实现完整的配置信息，搜索框架提供了一系列配置类，记 录配置信息，配置信息、分为两类，"静态配置信息"和"动态配置信息"，静态配置信息是在 开发时需要事先配置，动态配置信息不需要再开发时配置，而是在运行的过程中动态生成。
[0014] 搜索平台提供的配置类和搜索服务类：
[0015]1?节点配置类SearchNodeComConfigure:在实际查询中，每一个的后台"服务实 体"节点将对应一个节点配置类，用于保存该节点对应的搜索配置信息。配置参数包括： 节点名称，服务实体名称，上下游节点的对应关系，搜索节点编号等等，这些信息在应用场 景开发过程中需要手动配置，以提交给系统。动态配置信息包括：数据库表名称，初始SQL 语句查询条件，有效性标示符等等，这些信息在搜索的运行工程中，根据用户的输入查询参 数，动态生成。
[0016] 2.字段配置注解SearchFieldConfig:该注解在设计前台搜索视图模型时，需要 引用，以表示前台模型中每个字段和后台服务视图节点字段的对应关系。
[0017] 3.搜索字段配置类SEFieldSearchConfig :每一个搜索的字段，将对应一个该类 的实例，这个类中的配置信息在运行过程中，框架通过动态解析前台搜索视图类，每个字段 的注解，自动生成，并且填充相关的配置信息、，并且将这些字段配置类的实例通过列表的 方式聚合，作为节点配置类的熟悉，该类所有的配置信息都是"动态配置信息"，在运行过程 中动态生成。
[0018] 4.搜索框架除了这些配置接口类，还提供了一个核心的服务类SearchService来 真正执行搜索的全部过程，该类暴露公共方法doSearch:
[0019] doSearch(SEUIComModel seUlComModel, List<SearchNodeComConfigure>
[0020] searchNodeConfigList, boolean fuzzyFlag)
[0021] 来完成整个搜索过程。输入参数中：SEUIComModelsenComModel为实际运行中， 包含了用户输入查询参数的前台视图模型，List〈SearchNodeComConfigure>searchNodeCo nfigList为控制层传入的静态配置信息，以节点配置类SearchNodeComConfigur e的列表 作为参数，booleanfuzzyFlag为是否需要模糊查询的标识。
[0022] 搜索平台搜索实现的详细过程
[0023] 步骤1:静态配置
[0024] 在每个搜索应用场景的开发中，开发人员首先需要使用代码手动配置这些场景 的信息，一是在搜索视图模型中，引用系统提供的JAVA注解接口SearchFieldConfig， 指明视图模型中每个字段和后台"服务实体"模型中那个字段相关联，该字段属于哪 一个搜索节点。二是在MVC架构的视图控制类中，配置搜索节点配置信息，即生成类 SearchNodeComConfigure实例，并且传递给后台。这里节点配置包含了前台视图模型和后 台"服务实体"模型的关系：前台模型需要关系到后台"服务实体"模型的哪些节点类，这些 节点按照什么逻辑前后连接起来。
[0025] "逻辑关系路径"的概念：配置信息中包含的各个"服务实体"节点，总是从某一个 "起始节点"出发，按照一定的逻辑关系，关联到下游一个或者多个搜索节点。我们把每一条 从"起始节点"，按照某种关联关系，关联到最后一个节点，形成的逻辑路线，成为"逻辑关系 路径"，在搜索的后面步骤中，每条逻辑关系路径，将会生成一条完整的SQL查询语句，逻辑 关系路径上的每一对关联关系和每个节点上的搜索条件，将会成为查询语句的查询条件。
[0026] 附录图1描述了"逻辑关系路径"生成的示意图：起始节点为"节点A"，按照一定 的逻辑关系分别关联到后面一系列下游节点，节点C，E，F为最下游节点，从最下游节点开 始，图中的节点生成了三条"逻辑关系路径" ：1.C->B->A，2.E->D->A，3.F->D->A。注意这些 上下游节点的关联关系都是"星型业务模型"，和业务模型构成相关，比如有"父子关系":即 上游节点为父节点，上游节点和下游节点是父子关系，再比如"引用关系":上下游节点是引 用关系，上游节点是引用关系的源节点，下游节点为引用关系的目标节点。
[0027] 实例1 :为了更清楚地说明"逻辑关系路径"的原理和生成过程，我们引入一个实 际的搜索场景作为实例讲解：托运单搜索。请参看图2的托运单业务模型结构：
[0028] 托运单业务模型的构成：
[0029] 1.节点BookingNote:属于服务实体〈运单（BookingNote) >的根节点：包含了运 单号，开票时间，优先级别，目的城市等唯一型信息。
[0030] 2.节点Cargo:货物本身信息节点：为服务实体：〈货物（Cargo) >的根节点，包含 了货物的名称，编号，货物的性质等等信息。
[0031] 3.节点BookingNoteParty:属于服务实体〈运单（BookingNote) >，运单参与者节 点，表示运单的参与者信息，如发货方，收货方等等，并且引用到真正的客户实体节点上。
[0032]4?节点Customer:属于服务实体〈客户（Customer) >的根节点：包含了客户姓名， 编号，电话，地址等信息。
[0033] 根据图2描述的搜索场景，一共有7个搜索节点：1.BookingNote(运单）_Root, 2.BookingNoteCargo(运单货物），3.Cargo(货物），4.BookingNoteParty:运单发货方， 5.Customer:发货方客户，6.BookingNoteParty:运单收货方，7.Customer:收货方客户。 [0034] 根节点是"运单"，从三个末端节点："收货方客户"，"发货方客户"，"货物"出发，一 直到根节点，一共可以串联出3条"逻辑关系路径"：
[0035] 1?收货方客户_>运单收货方_>运单。
[0036] 2.发货方客户_>运单发货方_>运单。
[0037] 3.货物_>运单货物_>运单。
[0038] 步骤2:动态配置
[0039] 开发人员完成"静态配置"后，将静态配置的信息提交给搜索框架，框架自动生成 "动态配置信息":这个过程包括：1.动态读取视图模型，分析每个字段是否包含有效的查询 条件。2.对包含了有效查询条件的字段，动态生成字段配置类，填充到对应的搜索节点配置 类中。3.根据输入条件，判断每个节点是否为有效查询节点。
[0040] 图3表示了静态动态配置的示意图，动态配置中，搜索节点配置类实例首先为静 态配置过程中提供，同时动态配置根据实际输入的查询条件动态填充，搜索字段配置类为 动态配置过程中动态生成，并且作为节点配置类的属性。
[0041] 实际查询中，用户的搜索信息总是通过绑定在n上的视图模型提交给后台，视图 模型上包含了若干字段，如前面所说，这些字段和后台服务实体模型的字段相互对应，但不 是所有的字段都是有效的搜索条件，都会转化成SQL语句的查询条件，只有那些用户真正 制定了数值的字段，才是有效的查询条件，而用户没有输入值的字段，被系统认为是无效的 查询条件，被过滤掉。
[0042] 在这个过程中，搜索框架会动态分析每一个绑定在视图模型上的字段，判断该字 段绑定的值和字段的类型，根据类型判断该字段是否为有效的搜索条件，比如，当字段是字 符型变量，而绑定的值为空时，认为该字段为无效的搜索条件。
[0043] 动态配置的第二个步骤：系统将会处理包含有效查询条件的字段，找出它属于哪 个搜索节点，动态地加入到对应搜索节点配置类的属性中。
[0044] 动态配置的第三个步骤：当该查询节点包含了有效的查询条件时，我们认为该节 点是有效的节点，这个节点的有效性在后面生成动态逻辑关系路径和SQL查询生成很重 要：当节点是无效的节点，我们在生成动态的逻辑关系路径时，可以把无效的节点去掉。
[0045] 步骤3:动态生成逻辑关系路径
[0046] 前面的实例1以托运单搜索为例，如何生成逻辑关系路径，但那里的逻辑关系路 径是从设计时态的角度，根据静态的模型结构，构建出的"静态逻辑关系路径"。实际搜索过 程中，除了通过静态的逻辑关系路径外，搜索框架还会根据实际输入的查询条件，对静态逻 辑关系路径进行进一步处理，去掉无效的搜索节点，合并可以合并的路径，形成可以直接使 用的动态逻辑关系路径。
[0047] 步骤4:根据有效的逻辑关系路径生成SQL查询命令
[0048] 每一条有效的逻辑关系路径都会生成一条有效的SQL搜索命令，生成的过程分为 几个步骤：1.每个包含查询条件的节点，生成SQL语句查询条件；2.上下游节点的关联条 件，生成SQL语句连接条件；3.从"起始节点"开始，直到最后一个包含有效查询条件的节点 为止，循环步骤1，2生成有效的SQL查询语句。
[0049] 生成SQL查询语句的第一个步骤：每个节点生成SQL查询条件。
[0050] 当该搜索节点包含有效的查询条件时，搜索节点配置类SearchNodeComConfigure 包含搜索字段配置类SEFieldSearchConfig的列表实例作为其属性。搜索框架会在运 行该步骤时，遍历这个列表属性，根据搜索字段的名称和绑定的值，并且按照这样的公式 Where(〈属性名称1>=〈属性值l>)and(〈属性名称2>=〈属性值2>)......构建出查询条 件。
[0051] 实例1中，同时请查看示意图2。假设用户输入的查询条件中，搜索节点："收货方 客户"包含查询信息：姓名：name="王小二"，联系电话：mobile=" 13880888888"。则该节 点："收货方客户"为有效的搜索节点，且这个节点配置类中包含两个字段（name，mobile) 配置类的实例，作为属性。搜索框架在处理过程中，遍历这两个实例，生成该节点的查讯条 件：Wherename="王小二"andmobile=" 13880888888"。
[0052] 第二、三个步骤，根据上下游关联关系，生成有效的SQL查询语句
[0053] 同时"收货方客户"所在的"逻辑关系路径"为customer(收货方客 户）-&g t;BookingNoteParty(运单客户：收货方）->BookingNote(运单）。一共三个搜索节点， 假设后面两个节点不包含有效的搜索条件，但是因为"收货方客户"节点处于逻辑关系路 径的下游，包含了有效搜索条件，不能被忽略掉，上游的两个节点，即使没有有效的搜索条 件，也必须作为有效节点，生成SQL查询条件。
[0054]从customer_>BookingNoteParty，，因为这两个节点是引用关系，根据星型业务模 型的框架，引用关系，即有这样的关联关系：bookingNoteParty.refUUID=customer.uuid, 这样的关联可以转换为SQL条件：fromBookingNotePartywhererefUUIDin(select uuidfromCustomerwhere.....)〇
[0055] 同理，从BookinNoteParty到BookingNote，由于是父子关系。根据星型业务模型 的框架，有这样的关联关系：bookingNote.uuid=bookingNoteParty.parentNodeUUID。这样 的关联关系装换为SQL条件：fromBookingNotewhereuuidin(selectparentNodeUUID fromBookingNotePartywhere......)〇
[0056] 搜索框架将该"逻辑关系路径"上所有节点的SQL查询语句串联起来，加 上必要的连接符号，生成的可以直接SQL查询语句为：selectbookingNotefrom BookingNotewhereuuidin(selectparentNodeUUIDfromBookingNoteParty whererefUUIDin(selectuuidfromCustomerwhereWherename="王小二"and m〇bile=" 13880888888" )))。该语句可以直接交给数据库执行，返回满足该逻辑路径的 查询结果。
[0057] 每条逻辑关系路径在生成了有效的SQL语句后，框架提交数据库进行搜索，并且 按照uuid(框架中服务实体实例的唯一标示符）合并重复的服务实体实例，并且返回有效 的查询值。
【附图说明】
[0058] 图1描述了简单的逻辑关系路线图实例。
[0059] 图2以"托运单搜索"为业务场景，描述了逻辑关系路线图的生成原理。
[0060] 图3描述了搜索框架配置过程的原理。
【具体实施方式】
[0061] 1.系统准备：本动态搜索框架实现的基础是基于星型结构的通用数据模型框 架，该框架的实现，需要做下列系统准备：在JAVA工程中，引入服务实体平台的工程包：service.platform, jar。
[0062] 2.搜索框架的使用过程，可以大致分为这样的步骤：1.搜索视图模型的生成和调 整，2.静态配置，3.调用搜索框架实现搜索。
[0063] 3.实现步骤1:视图搜索模型的生成和调整：
[0064] 如前面所述，页面数据的搜索，总是将视图搜索模型绑定在页面上，目前大量的前 端页面技术如spring mvC都支持这样的实现方式。而搜索模型总是绑定到列表视图页面 上，这样通过搜索模型搜索出来的结果可以直接通过列表视图来显示。理论上说：列表视 图模型和搜索视图模型可以是完全一致的，即所有列表视图显示的字段都可以用来搜索。 目前的快速搜索框架页支持对所有相关字段实现搜索功能，只需要配置好所有相关的后台 "服务实体"模型节点，不需要额外的工作量。
[0065] 基于这样的理论，搜索框架提供了方法，可以直接从现有的列表视图模型，生成搜 索视图模型：在对列表视图模型所有字段进行复制后，通过星型数据模型框架，得出每个字 段和后台"服务实体"模型的前后连接关系，并对每个字段生成相应的搜索注解，加到搜索 视图模型上。当然实际使用中，还需要对搜索视图的字段进行调整，比如出于页面美观、简 洁的考虑，需要删除没有必要搜索的字段。
[0066] 系统提供了接口，通过编程的方式，输入视图模型的类，运行程序以后，在视图模 型同一个包下面生成相关的搜索模型，自动包含了视图模型所有的字段。
[0067]工具类：plotformfoundotion lnstallotion.WebPage. DefaultSearchMoJuleGenService
[0068]生成方法：genSearchModelClassFile (String modelNome，Class〈？>uModelCls)。
[0069] 其中，modeiName是为了给搜索视图的类命名，uiModelCis为对应列表视图的类。
[0070] 使用实例：
[0071]
[0072] 该实例中，通过运单的视图模型：BookingNoteUiModel，通过调用 genSearchModelClassFile方法生成了对应的搜索视图类。
[0073] 生成的搜索视图类部分代码：
[0075]字段bookID，destCityName，weightLow，weightHigh都是从运单的视图模型中 得到，且每个字段上面都加上了SearchFieldConfig的注解，表示该字段和后台"服务实 体"模型中每个字段和节点的关联关系。注意这里的字段weightHigh和weightLow，都对 应到后台的同一个字段：weight,但是注解中fieldType的值，一个为SearchFieldConfig. FIELDTYPE_L0W和SearchFieldConfig. FIELDTYPE_HIGH，表面了一个对应为该搜索字段的 低位值，一个为高位值。实际搜索中，比如需要搜索重量为100到200公斤重的托运单，这 可以采用这样的配置。
[0076] 实现步骤2、3 :静态配置的实现过程：在视图控制类controller中，对每一个后 台搜索节点：生成节点配置类SearchNodeComConfigure的实例，并且填充属性：nodeName、 seName、nodelnstID、toBaseNodeType等等。并且将节点配置类实例，构建成集合，传给搜 索框架核心服务类SearchService，实现搜索过程，并且返回搜索结果。
[0077] 静态配置代码实例：
[0078]
【主权项】
1. 本发明描述的快速搜索框架，基础是星型结构的业务模型，核心是实现了搜索过程 和搜索业务场景的隔离，利用手动配置和星型结构模型框架提供的信息，能够根据用户的 输入，动态生成满足搜索要求的SQL语句，实现了数据搜索的统一框架实现。2. 根据权利要求1所描述的快速搜索框架，所实现的统一数据搜素，开发人员在具体 实现场景中需要少量的配置代码来向框架传递场景信息，称为静态配置。3. 根据权利要求2,所描述的静态配置信息，框架会自动根据配置信息和运行时软件 客户输入的查询条件，自动匹配到后台每个相关的数据库表和字段，并生成相关的SQL搜 索语句，称为动态配置，并实现搜索。
【专利摘要】本发明设计了基于星型结构业务模型的快速搜索框架。基本思路是：将搜索的业务场景和搜索过程分离，实现去耦合，实现了数据搜索的统一化处理。开发搜索场景时，只需要做简要的配置信息，搜索框架根据用户的输入，利用统一业务模型框架提供的信息，能动态生成满足要求的SQL语句，并实现搜索功能。实现搜索的统一化处理，克服了普通页面数据搜索开发中，开发量大，维护和扩展困难的问题。动态搜索的实现过程，在不同的搜索场景中，提供少量静态配置信息，框架自动根据前台搜索条件，生成动态配置信息，然后生成逻辑关系路径，并转换为SQL语句搜索条件，执行搜索并返回结果。
【IPC分类】G06F17/30
【公开号】CN104899205
【申请号】CN201410077837
【发明人】张航
【申请人】张航
【公开日】2015年9月9日
【申请日】2014年3月5日
【技术领域】：
[0001] 本发明设计了一种标准高效的动态搜索框架，其思想是：利用通用结构模型的数 据统一化处理特点，克服普通搜索技术和业务场景密切绑定的问题，克服普通搜索技术在 不同的业务场景下，开发维护量大，且工程量随着用户搜索条件的增加而急剧增大的问题。 使用本搜索框架，在实际应用中，只需少量的配置，实现了多种不同业务场景下，数据搜索 统一模式实现的问题，降低了开发、维护和后期扩展的工作量。
[0002] 本动态搜索框架的核心是一种基于星型结构的通用数据模型，我们称为"服务实 体（ServiceEntity) "。通过星型的数据结构来描述不同的业务逻辑，使得模型的结构实现 了统一化，并且提供了相关框架实现了数据的统一化处理。在此基础上发明了快速搜索框 架，在不同的搜索业务场景中，只需要做简单的配置，搜索框架根据简单的配置和统一化数 据框架，自动获取足够的搜索业务场景信息，并且根据用户实际输入，动态生成各种复杂的 SQL查询语句，实现多样化的业务场景下，搜索功能的统一模式实现。
【背景技术】：
[0003] 当前页面数据搜索普遍采用的技术：由于商务软件的实际应用场景千差万别，搜 索数据面临的应用场景也千差万别，目前没有固定的前台数据搜索技术来优化工作模式， 普遍采用的搜索技术都具有"零时性"的特点：一般在实际中采用手动设计的方式：根据前 台的输入数据，事先预测好各种可能的搜索条件，设置好各种场景用到的SQL语句，根据用 户在前台的输入，后台判断条件，决定采用哪些的SQL语句。
[0004] 目前搜索技术面临的问题：
[0005] 灵活性差：各种搜索的SQL语句在事先定义好，实际上将搜索过程和具体的场景 密切绑定在一起，必须事先根据可能的搜索情况定义好所有可能的SQL语句，工作量大，前 台能够接受的搜索条件比较有限。目前大部分软件在搜索视图中，能够提供的搜索条件比 较有限，特别是搜索字段对应后台多张数据库表，且前台对应的搜索条件很多，实现起来难 度很大。
[0006] 扩展型差：当在前台增加搜索条件时，所有预先定义的SQL语句可能都会改动。特 别是当后台涉及的表有变化时，增加表或者减少表，不仅所有的SQL语句会重新设计，因为 搜索条件变了，而且搜索场景也需要重新定义。
[0007] 通用性差：在不同的使用场景中，可能需要全部重新设计搜索逻辑。
[0008] 这样造成的后果是：目前大部分软件出于开发量和后期维护的考虑，在用户界面 上只能提供少量的查询条件，比如十个以内，当用户界面上提供的查询条件变多了后，特别 是查询条件涉及到后台多张表联合查询时，工作量会大大增加。从使用者角度上说，商务软 件只要在提供列表视图的页面上，都应该提供丰富的查询功能，才能使得用户能灵活高效 地发挥列表视图的特点。但是通过调查发现，目前大量的商务软件，提供的查询功能都比较 有限，不能做到随时随地，任何形式的数据都提供的查询功能，大部分软件都将查询功能单 独列举出来，只提供有限的查询功能，且只开放给比较核心的数据。
[0009] 星型结构的通用业务模型简介：领域驱动开发模式的提出，使得传统的面向对象 的软件开发中引入了各个部门都能使用，能交流的统一领域模型，使得软件开发更加面向 实际业务需求。但是，在没有统一的业务模型支持的框架下，实际的开发模型普遍是贫血的 JAVA基本数据类（JAVAP0J0类），开发模型和业务模型有不小的区别，需要花费大量精力 实现两种模型的转换；另一方面，实际的业务模型结构是千差万别的，在不同的业务场景， 需要不同的方法来处理不同的业务模型，增加了开发和维护的难度。基于星型结构的通用 业务模型，采用了通用的结构来描述不同场景的业务模型，一方面，使得开发模型和领域模 型实现了合并，直接通过领域模型实现建模，体现而来领域驱动建模ODD)的思想，同时， 统一化的模型使得数据的处理和维护变得简化，进一步使得统一框架来实现数据处理成为 可能。
[0010] 本发明设计了一种基于星型结构的数据模型上的动态搜索框架，该框架实现了搜 索过程和具体的业务场景隔离，具体业务场景由配置信息和统一数据框架提供，在实际应 用中，进行一些简单的配置后，可以自适应实现多种情况下的搜索，框架会根据前台视图模 型传入的搜索参数，自动生成搜索条件，自动找到所有应用到的数据库表，并动态生成各种 场景下的SQL语句，进行搜索。
[0011] 和传统的搜索技术相比，开发的工作量大大减少，维护的工作也大大减少，如果场 景发生变化，不管是变更视图模型的字段或者变更后台搜索的表，只需要调整搜索配置参 数就可以，杜绝了普通搜索技术由于涉及到的搜索字段和后台数据库表增加而开发量，维 护量成几何增加的问题。
【发明内容】
：
[0012] 本动态搜索框架的下，搜索的实现过程大致为：首先生成搜索场景配置信息、，配 置信息生成由两个阶段构成："静态配置"和"动态配置"，"静态配置"需要开发人员在开发 过程中手动配置，"动态配置"是指在实际运行过程中，根据统一化数据框架和用户输入的 搜索信息，动态生成。然后框架根据完整的配置信息生成"逻辑关系路径"，每条路径由唯一 的"起始节点"出发，根据一系列关联条件，直到最后一个节点为止。再然后，基于"搜索逻 辑路径"，生成SQL语句的搜索条件，并且再次合并路径，直到生成最终的搜索SQL语句。最 后步骤是系统执行搜索命令，并返回搜索结果。
[0013]如前面所述：搜索的实现实现过程可以分为五个阶段：1.静态配置，2.动态配置， 3.动态生成逻辑关系路径，4.生成SQL搜索语句，5执行搜索。前面两个步骤都是为搜索框 架提供完整的搜索配置信息。为了实现完整的配置信息，搜索框架提供了一系列配置类，记 录配置信息，配置信息、分为两类，"静态配置信息"和"动态配置信息"，静态配置信息是在 开发时需要事先配置，动态配置信息不需要再开发时配置，而是在运行的过程中动态生成。
[0014] 搜索平台提供的配置类和搜索服务类：
[0015]1?节点配置类SearchNodeComConfigure:在实际查询中，每一个的后台"服务实 体"节点将对应一个节点配置类，用于保存该节点对应的搜索配置信息。配置参数包括： 节点名称，服务实体名称，上下游节点的对应关系，搜索节点编号等等，这些信息在应用场 景开发过程中需要手动配置，以提交给系统。动态配置信息包括：数据库表名称，初始SQL 语句查询条件，有效性标示符等等，这些信息在搜索的运行工程中，根据用户的输入查询参 数，动态生成。
[0016] 2.字段配置注解SearchFieldConfig:该注解在设计前台搜索视图模型时，需要 引用，以表示前台模型中每个字段和后台服务视图节点字段的对应关系。
[0017] 3.搜索字段配置类SEFieldSearchConfig :每一个搜索的字段，将对应一个该类 的实例，这个类中的配置信息在运行过程中，框架通过动态解析前台搜索视图类，每个字段 的注解，自动生成，并且填充相关的配置信息、，并且将这些字段配置类的实例通过列表的 方式聚合，作为节点配置类的熟悉，该类所有的配置信息都是"动态配置信息"，在运行过程 中动态生成。
[0018] 4.搜索框架除了这些配置接口类，还提供了一个核心的服务类SearchService来 真正执行搜索的全部过程，该类暴露公共方法doSearch:
[0019] doSearch(SEUIComModel seUlComModel, List<SearchNodeComConfigure>
[0020] searchNodeConfigList, boolean fuzzyFlag)
[0021] 来完成整个搜索过程。输入参数中：SEUIComModelsenComModel为实际运行中， 包含了用户输入查询参数的前台视图模型，List〈SearchNodeComConfigure>searchNodeCo nfigList为控制层传入的静态配置信息，以节点配置类SearchNodeComConfigur e的列表 作为参数，booleanfuzzyFlag为是否需要模糊查询的标识。
[0022] 搜索平台搜索实现的详细过程
[0023] 步骤1:静态配置
[0024] 在每个搜索应用场景的开发中，开发人员首先需要使用代码手动配置这些场景 的信息，一是在搜索视图模型中，引用系统提供的JAVA注解接口SearchFieldConfig， 指明视图模型中每个字段和后台"服务实体"模型中那个字段相关联，该字段属于哪 一个搜索节点。二是在MVC架构的视图控制类中，配置搜索节点配置信息，即生成类 SearchNodeComConfigure实例，并且传递给后台。这里节点配置包含了前台视图模型和后 台"服务实体"模型的关系：前台模型需要关系到后台"服务实体"模型的哪些节点类，这些 节点按照什么逻辑前后连接起来。
[0025] "逻辑关系路径"的概念：配置信息中包含的各个"服务实体"节点，总是从某一个 "起始节点"出发，按照一定的逻辑关系，关联到下游一个或者多个搜索节点。我们把每一条 从"起始节点"，按照某种关联关系，关联到最后一个节点，形成的逻辑路线，成为"逻辑关系 路径"，在搜索的后面步骤中，每条逻辑关系路径，将会生成一条完整的SQL查询语句，逻辑 关系路径上的每一对关联关系和每个节点上的搜索条件，将会成为查询语句的查询条件。
[0026] 附录图1描述了"逻辑关系路径"生成的示意图：起始节点为"节点A"，按照一定 的逻辑关系分别关联到后面一系列下游节点，节点C，E，F为最下游节点，从最下游节点开 始，图中的节点生成了三条"逻辑关系路径" ：1.C->B->A，2.E->D->A，3.F->D->A。注意这些 上下游节点的关联关系都是"星型业务模型"，和业务模型构成相关，比如有"父子关系":即 上游节点为父节点，上游节点和下游节点是父子关系，再比如"引用关系":上下游节点是引 用关系，上游节点是引用关系的源节点，下游节点为引用关系的目标节点。
[0027] 实例1 :为了更清楚地说明"逻辑关系路径"的原理和生成过程，我们引入一个实 际的搜索场景作为实例讲解：托运单搜索。请参看图2的托运单业务模型结构：
[0028] 托运单业务模型的构成：
[0029] 1.节点BookingNote:属于服务实体〈运单（BookingNote) >的根节点：包含了运 单号，开票时间，优先级别，目的城市等唯一型信息。
[0030] 2.节点Cargo:货物本身信息节点：为服务实体：〈货物（Cargo) >的根节点，包含 了货物的名称，编号，货物的性质等等信息。
[0031] 3.节点BookingNoteParty:属于服务实体〈运单（BookingNote) >，运单参与者节 点，表示运单的参与者信息，如发货方，收货方等等，并且引用到真正的客户实体节点上。
[0032]4?节点Customer:属于服务实体〈客户（Customer) >的根节点：包含了客户姓名， 编号，电话，地址等信息。
[0033] 根据图2描述的搜索场景，一共有7个搜索节点：1.BookingNote(运单）_Root, 2.BookingNoteCargo(运单货物），3.Cargo(货物），4.BookingNoteParty:运单发货方， 5.Customer:发货方客户，6.BookingNoteParty:运单收货方，7.Customer:收货方客户。 [0034] 根节点是"运单"，从三个末端节点："收货方客户"，"发货方客户"，"货物"出发，一 直到根节点，一共可以串联出3条"逻辑关系路径"：
[0035] 1?收货方客户_>运单收货方_>运单。
[0036] 2.发货方客户_>运单发货方_>运单。
[0037] 3.货物_>运单货物_>运单。
[0038] 步骤2:动态配置
[0039] 开发人员完成"静态配置"后，将静态配置的信息提交给搜索框架，框架自动生成 "动态配置信息":这个过程包括：1.动态读取视图模型，分析每个字段是否包含有效的查询 条件。2.对包含了有效查询条件的字段，动态生成字段配置类，填充到对应的搜索节点配置 类中。3.根据输入条件，判断每个节点是否为有效查询节点。
[0040] 图3表示了静态动态配置的示意图，动态配置中，搜索节点配置类实例首先为静 态配置过程中提供，同时动态配置根据实际输入的查询条件动态填充，搜索字段配置类为 动态配置过程中动态生成，并且作为节点配置类的属性。
[0041] 实际查询中，用户的搜索信息总是通过绑定在n上的视图模型提交给后台，视图 模型上包含了若干字段，如前面所说，这些字段和后台服务实体模型的字段相互对应，但不 是所有的字段都是有效的搜索条件，都会转化成SQL语句的查询条件，只有那些用户真正 制定了数值的字段，才是有效的查询条件，而用户没有输入值的字段，被系统认为是无效的 查询条件，被过滤掉。
[0042] 在这个过程中，搜索框架会动态分析每一个绑定在视图模型上的字段，判断该字 段绑定的值和字段的类型，根据类型判断该字段是否为有效的搜索条件，比如，当字段是字 符型变量，而绑定的值为空时，认为该字段为无效的搜索条件。
[0043] 动态配置的第二个步骤：系统将会处理包含有效查询条件的字段，找出它属于哪 个搜索节点，动态地加入到对应搜索节点配置类的属性中。
[0044] 动态配置的第三个步骤：当该查询节点包含了有效的查询条件时，我们认为该节 点是有效的节点，这个节点的有效性在后面生成动态逻辑关系路径和SQL查询生成很重 要：当节点是无效的节点，我们在生成动态的逻辑关系路径时，可以把无效的节点去掉。
[0045] 步骤3:动态生成逻辑关系路径
[0046] 前面的实例1以托运单搜索为例，如何生成逻辑关系路径，但那里的逻辑关系路 径是从设计时态的角度，根据静态的模型结构，构建出的"静态逻辑关系路径"。实际搜索过 程中，除了通过静态的逻辑关系路径外，搜索框架还会根据实际输入的查询条件，对静态逻 辑关系路径进行进一步处理，去掉无效的搜索节点，合并可以合并的路径，形成可以直接使 用的动态逻辑关系路径。
[0047] 步骤4:根据有效的逻辑关系路径生成SQL查询命令
[0048] 每一条有效的逻辑关系路径都会生成一条有效的SQL搜索命令，生成的过程分为 几个步骤：1.每个包含查询条件的节点，生成SQL语句查询条件；2.上下游节点的关联条 件，生成SQL语句连接条件；3.从"起始节点"开始，直到最后一个包含有效查询条件的节点 为止，循环步骤1，2生成有效的SQL查询语句。
[0049] 生成SQL查询语句的第一个步骤：每个节点生成SQL查询条件。
[0050] 当该搜索节点包含有效的查询条件时，搜索节点配置类SearchNodeComConfigure 包含搜索字段配置类SEFieldSearchConfig的列表实例作为其属性。搜索框架会在运 行该步骤时，遍历这个列表属性，根据搜索字段的名称和绑定的值，并且按照这样的公式 Where(〈属性名称1>=〈属性值l>)and(〈属性名称2>=〈属性值2>)......构建出查询条 件。
[0051] 实例1中，同时请查看示意图2。假设用户输入的查询条件中，搜索节点："收货方 客户"包含查询信息：姓名：name="王小二"，联系电话：mobile=" 13880888888"。则该节 点："收货方客户"为有效的搜索节点，且这个节点配置类中包含两个字段（name，mobile) 配置类的实例，作为属性。搜索框架在处理过程中，遍历这两个实例，生成该节点的查讯条 件：Wherename="王小二"andmobile=" 13880888888"。
[0052] 第二、三个步骤，根据上下游关联关系，生成有效的SQL查询语句
[0053] 同时"收货方客户"所在的"逻辑关系路径"为customer(收货方客 户）-&g t;BookingNoteParty(运单客户：收货方）->BookingNote(运单）。一共三个搜索节点， 假设后面两个节点不包含有效的搜索条件，但是因为"收货方客户"节点处于逻辑关系路 径的下游，包含了有效搜索条件，不能被忽略掉，上游的两个节点，即使没有有效的搜索条 件，也必须作为有效节点，生成SQL查询条件。
[0054]从customer_>BookingNoteParty，，因为这两个节点是引用关系，根据星型业务模 型的框架，引用关系，即有这样的关联关系：bookingNoteParty.refUUID=customer.uuid, 这样的关联可以转换为SQL条件：fromBookingNotePartywhererefUUIDin(select uuidfromCustomerwhere.....)〇
[0055] 同理，从BookinNoteParty到BookingNote，由于是父子关系。根据星型业务模型 的框架，有这样的关联关系：bookingNote.uuid=bookingNoteParty.parentNodeUUID。这样 的关联关系装换为SQL条件：fromBookingNotewhereuuidin(selectparentNodeUUID fromBookingNotePartywhere......)〇
[0056] 搜索框架将该"逻辑关系路径"上所有节点的SQL查询语句串联起来，加 上必要的连接符号，生成的可以直接SQL查询语句为：selectbookingNotefrom BookingNotewhereuuidin(selectparentNodeUUIDfromBookingNoteParty whererefUUIDin(selectuuidfromCustomerwhereWherename="王小二"and m〇bile=" 13880888888" )))。该语句可以直接交给数据库执行，返回满足该逻辑路径的 查询结果。
[0057] 每条逻辑关系路径在生成了有效的SQL语句后，框架提交数据库进行搜索，并且 按照uuid(框架中服务实体实例的唯一标示符）合并重复的服务实体实例，并且返回有效 的查询值。
【附图说明】
[0058] 图1描述了简单的逻辑关系路线图实例。
[0059] 图2以"托运单搜索"为业务场景，描述了逻辑关系路线图的生成原理。
[0060] 图3描述了搜索框架配置过程的原理。
【具体实施方式】
[0061] 1.系统准备：本动态搜索框架实现的基础是基于星型结构的通用数据模型框 架，该框架的实现，需要做下列系统准备：在JAVA工程中，引入服务实体平台的工程包：service.platform, jar。
[0062] 2.搜索框架的使用过程，可以大致分为这样的步骤：1.搜索视图模型的生成和调 整，2.静态配置，3.调用搜索框架实现搜索。
[0063] 3.实现步骤1:视图搜索模型的生成和调整：
[0064] 如前面所述，页面数据的搜索，总是将视图搜索模型绑定在页面上，目前大量的前 端页面技术如spring mvC都支持这样的实现方式。而搜索模型总是绑定到列表视图页面 上，这样通过搜索模型搜索出来的结果可以直接通过列表视图来显示。理论上说：列表视 图模型和搜索视图模型可以是完全一致的，即所有列表视图显示的字段都可以用来搜索。 目前的快速搜索框架页支持对所有相关字段实现搜索功能，只需要配置好所有相关的后台 "服务实体"模型节点，不需要额外的工作量。
[0065] 基于这样的理论，搜索框架提供了方法，可以直接从现有的列表视图模型，生成搜 索视图模型：在对列表视图模型所有字段进行复制后，通过星型数据模型框架，得出每个字 段和后台"服务实体"模型的前后连接关系，并对每个字段生成相应的搜索注解，加到搜索 视图模型上。当然实际使用中，还需要对搜索视图的字段进行调整，比如出于页面美观、简 洁的考虑，需要删除没有必要搜索的字段。
[0066] 系统提供了接口，通过编程的方式，输入视图模型的类，运行程序以后，在视图模 型同一个包下面生成相关的搜索模型，自动包含了视图模型所有的字段。
[0067]工具类：plotformfoundotion lnstallotion.WebPage. DefaultSearchMoJuleGenService
[0068]生成方法：genSearchModelClassFile (String modelNome，Class〈？>uModelCls)。
[0069] 其中，modeiName是为了给搜索视图的类命名，uiModelCis为对应列表视图的类。
[0070] 使用实例：
[0071]
[0072] 该实例中，通过运单的视图模型：BookingNoteUiModel，通过调用 genSearchModelClassFile方法生成了对应的搜索视图类。
[0073] 生成的搜索视图类部分代码：
[0075]字段bookID，destCityName，weightLow，weightHigh都是从运单的视图模型中 得到，且每个字段上面都加上了SearchFieldConfig的注解，表示该字段和后台"服务实 体"模型中每个字段和节点的关联关系。注意这里的字段weightHigh和weightLow，都对 应到后台的同一个字段：weight,但是注解中fieldType的值，一个为SearchFieldConfig. FIELDTYPE_L0W和SearchFieldConfig. FIELDTYPE_HIGH，表面了一个对应为该搜索字段的 低位值，一个为高位值。实际搜索中，比如需要搜索重量为100到200公斤重的托运单，这 可以采用这样的配置。
[0076] 实现步骤2、3 :静态配置的实现过程：在视图控制类controller中，对每一个后 台搜索节点：生成节点配置类SearchNodeComConfigure的实例，并且填充属性：nodeName、 seName、nodelnstID、toBaseNodeType等等。并且将节点配置类实例，构建成集合，传给搜 索框架核心服务类SearchService，实现搜索过程，并且返回搜索结果。
[0077] 静态配置代码实例：
[0078]
【主权项】
1. 本发明描述的快速搜索框架，基础是星型结构的业务模型，核心是实现了搜索过程 和搜索业务场景的隔离，利用手动配置和星型结构模型框架提供的信息，能够根据用户的 输入，动态生成满足搜索要求的SQL语句，实现了数据搜索的统一框架实现。2. 根据权利要求1所描述的快速搜索框架，所实现的统一数据搜素，开发人员在具体 实现场景中需要少量的配置代码来向框架传递场景信息，称为静态配置。3. 根据权利要求2,所描述的静态配置信息，框架会自动根据配置信息和运行时软件 客户输入的查询条件，自动匹配到后台每个相关的数据库表和字段，并生成相关的SQL搜 索语句，称为动态配置，并实现搜索。
【专利摘要】本发明设计了基于星型结构业务模型的快速搜索框架。基本思路是：将搜索的业务场景和搜索过程分离，实现去耦合，实现了数据搜索的统一化处理。开发搜索场景时，只需要做简要的配置信息，搜索框架根据用户的输入，利用统一业务模型框架提供的信息，能动态生成满足要求的SQL语句，并实现搜索功能。实现搜索的统一化处理，克服了普通页面数据搜索开发中，开发量大，维护和扩展困难的问题。动态搜索的实现过程，在不同的搜索场景中，提供少量静态配置信息，框架自动根据前台搜索条件，生成动态配置信息，然后生成逻辑关系路径，并转换为SQL语句搜索条件，执行搜索并返回结果。
【IPC分类】G06F17/30
【公开号】CN104899205
【申请号】CN201410077837
【发明人】张航
【申请人】张航
【公开日】2015年9月9日
【申请日】2014年3月5日
最新回复(0)