查询建模构建一体化开发平台(一) 概览

  今天特别难受,写不下去代码。所以再来谈谈关于查询建模的内容。本系列一改上一个系列的风格，只谈架构及想法不谈具体技术实现。

  希望有经验的博友前来拍砖。

  上一个系列讲述了Silverlight实现查询建模的具体技术细节。架构及想法没有涉及。主要是考虑到产品还在脑子里没有付诸于实现。现在产品已经在公司立项，基本的设计及定位已经出炉。可以看做是宣传和取经。

  谈到模型大家各有各的理解。模型驱动的架构(MDA)理论其实已经比较成熟了，感兴趣的可以参看IBM的一系列研究http://www.ibm.com/developerworks/cn/rational/r-mda/,

IBM的研究主要依托其Rational产品。而我个人没有那么深厚的技术功底，咱就只能以一个程序员的狭隘角度大概说说自己的想法。在做企业级应用开发中我们最常处理的就是查询的列表、图表、统计、报表之类。这部分的工作量大概占到了开发的50%以上。而且随着用户素质的提高，自定义查询、自定义统计....等等(变态需求)层出不穷。其实想想这部分的开发成本是最容易压缩的，只要工具支持到位完全可以通过配置把这些逻辑通用出来。这样提高了开发人员的效率以此削减了开发成本。而这些业务本身所依托的就是统一的数据模型。查询分析引擎的首要问题其实就是解决数据模型统一问题。(当然了解本项目的人很多都把查询分析引擎作为单一的表现层展现中间件，这么想其实有些片面，试想没有数据模型的支撑哪来数据的展现呢？)

  我们目前所做的就是用查询分析引擎建立统一的数据集模型,这些数据集模型可以方便的实现导入、导出、传递、复制、跨库。以这层模型统一现有项目的所有数据访问逻辑。包括平时程序员写的数据访问层代码、数据导入导出(ETL)逻辑、数据共享等。这样其实就是在平常业务数据的上层构建了一个以数据集组织的抽象层，这个层作为数据的整理和分类以及一些常用的数据处理(汇总、求和...)，并提供统一的接口共享及导入数据。程序员做项目过程中先根据需求建立统一的数据模型，然后写业务逻辑及页面代码。同时查询分析引擎也提供了相应的表现层配置，通过配置生成图表、列表的界面这就是主题模型。 表现层由于需求不同需要一个逐步渗透的过程，以后有可能程序员连展现层代码都不用写了直接配置生成页面。但这注定只能处理比较简单的需求。而此时数据集模型的灵活性往往制约上层模型及功能的设计及实现，同时决定了工具的易用性。

  说了这么多看看截图,总体的架构图还没有画以后补上吧。

  数据集管理页面:

  数据集配置界面(参数配置是重点体现灵活性):

 主题模型配置界面:提供简单的拖拽布局和Xaml代码

  目前产品还在初级阶段，以后细节想法即使和大家分享。