一个业务系统设计构想（一）

背景：

公司计划明年自主研发一个软件产品，公司有专人负责产品的策划和需求，我负责这个产品的技术架构方面。

这个产品属于一个典型的信息系统，从目前策划人员交给我的文档中，可以看出，系统规模较大，整体技术难度不高，但是也存在一些技术问题需要解决。

一、基础资料与单据需要有完全的自定义功能。即用户可以根据自身需要对基础资料和单据增删字段，字段类型包括基本的数据类型（字符串、日期、数值等），还包括基础资料和单据的引用类型。

二、系统需要支持离线和在线两种操作模式。对于离线操作模式，需要考虑数据同步和冲突的问题。

三、灵活的报表设计器。用户或者实施人员可以自行定义需要的数据报表，报表的来源可以是SQL语句，也可以是通过系统预设的取数公式来定义。

等等。。其他的还没考虑到。

解决办法构思：

第一个问题：

     一般能想到的做法是这样的，以基础资料的自定义字段为例，建立一个字段描述表，每条记录对应着基础资料表的每个字段，界面呈现、保存时先读取字段描述表，根据字段描述表中的记录动态生成SQL来读写基础资料表。单据的情况大致类似，只是字段描述表要复杂得多。

     这样的做法看似简单易行，但也有很多的问题：

     1.从软件设计的角度来说，缺少了领域模型，通常设计人员拿到需求之后，首先不是去设计数据库，而是考虑领域模型的构建，上述做法完全回避了领域模型的建立，直接让设计人员去设计数据库结构。

     2.对于动态生成的SQL，难以保证其安全性，也将软件产品绑定到特定的数据库系统。

     3.灵活性。某些字段需要进行特殊的验证或者需要根据其他的字段来计算得出。如果设计时没有考虑到的验证方式或计算方式，那么在实施过程中，还需要开发人员增加相应的代码。

     4.代码的复杂性。我曾经在一个项目中尝试使用上述方式，虽然项目最终验收了，但是“通过字段描述来动态生成SQL”的代码是惊人的复杂，维护的难度可想而知。

     为了避免项目中出现上述问题，我考虑采用以下方式实现：

     对于基础资料和业务单据，都有相应的领域模型（实体类），为了解决领域模型在编译后就固定不变的问题，可以将每个基础资料和单据都放在单独的程序集中，用户在更改了基础资料和业务单据后，系统根据用户的定义，自动生成实体类的代码和相应的描述文件，用户和实施人员是可以进行更改，然后编译为相应的程序集。

     界面的呈现和数据保存，界面上采用反射来实现。将来也有可能提供界面设计器之类的功能，将界面元素绑定到实体类的某个字段。

    

     以上的这些仅为个人想法，还不成熟，欢迎拍砖。如果有想应用到项目中的朋友欢迎交流。