企业应用平台设计杂想 (转)

 软件体系本身已经很复杂，更何况用以构建软件的框架。同计算机硬件的发展一样，我们只有在不断的学习、不断的思考中进步。从前人的经典中学习积累知识，从成功的实践中学习经验，从失败的过程中总结教训。本文的内容也正是我学习、实践、和思想的过程。希望能有效的与您沟通。

 

   首先，在诸如"架构"、"框架"这些词上请不要和我太计较。只要你能清楚我所要表达的意思就好，不要在为这些词语的解释上分散我们的主题。

   为了使我们的讨论清晰，而且能在我们掌控之中，我架设了一个以下的虚拟环境（此环境是现实的，为讨论方便做了一定程度的简化）。我们要针对以下的环境设计一套平台方案而不是做一个通用的商业软件平台。

一个虚拟的环境：

我们（M企业）为一个行业提供信息化系统整体解决方案。我们的客户（A 集团）的典型的组织架构是这样的:      首先我们不打算构建一个大型的ERP产品来满足各层级用户的需求。这样做有历史的原因、可行性、以及信息收集成本，系统集成成本、需求规范层级，而且这样做事有利可图的。我们可以做好多个项目，分别卖给A、B2、C3-1、C1-2。而且可以不断的为他们升级而在获取项目收益。      但这样以项目为核心的做法是企业陷入了一个很大的僵局。人员、资源、以及管理都出现了极大的浪费。    现在获得企业高层的支持。准备在我们的软件公司内部成立一个平台研发中心，目的在于构建一个基础的开发平台还搭建现有的5种类型的项目。   人力资源管理系统 --集团级、公司级、分公司级 物资管理系统     --公司级、分公司级 销售运输系统     --集团级、公司级别 财务系统（暂时由其他系统代替，考虑集成） --集团级、公司级、分公司级 管理战略分析系统 --集团级

 

出于种种因素的考虑，我订制了一个基本的不完善的平台目标，随后随着我们认识的不断提高会陆续增加新的内容。

平台的目标:

1. 极大的减少项目开发周期以及实施周期。
2. 稳固的底层框架、以及可扩展性。
3. 可配置的N层分布式物理架构。
4. 允许开发人员无障碍的使用。
5. 提高系统整体性能。
6. 助于VSX的IDE工具。
7. 提供非开发人员级别的现场辅助实施工具。
8. 尽可能的应对因需求变更，而需要对框架级别做出修改。

    当然现在我们的分析阶段还仅仅是构想可行性阶段，还没有引入真正的业务需求，而且我认为也还没有到那一步。可以先针对每一项目标还搜集一些好的想法。也不必太拘泥做出一些非常眩的模型图，当然为了思路方便我们可以使用白板和脑图。

 

    对于减少项目周期我想到了这些：

     我尽量从开发的角度考虑能够提高开发效率的方法，而不是从过程管理控制的角度出发。当然也有些很容易想到的东西被我遗忘了也是必然的。如：ORM工具。也许他提供了代码生成工具或数据库生成工具。但此刻我就想到这么多，即使想到的那也只是一些思路。我们可以从业务开发人员的角度在考虑这个话题。业务开发人员应该了解数据库吗？他们需要了解应用服务器吗？他们需要了解底层对象吗？对于业务开发人员来说，采取哪一种方式最为直观，或容易交流和掌握。（通常这种问题是无解的，每一种方案都由其优点和缺点，只能是找到一种折中的方法。）在回答这个问题之前先看看常用的三种设计思路。

关注数据或关注业务流程或关注界面

     讨论这个话题会直接关系到我们的开发过程方法，也许还会影响到这个框架的架构模式。从本身这三点来说很容易让我们想到三层架构，也许是他太根深蒂固的原因吧，但决不是我们唯一的选择。

     如果从数据为主体展开设计，则数据就是主体，业务开发人员需要先设计数据库，可以直接对原生态的数据进行控制、读取。平台可以提供一种业务类代码生成机制或运用现有的ORM产品。VS提供的强类型DataSet便是以这种方式设计的。开发人员可以很方便的根据数据库中的表、视图。生成对应的强类型的数据对象，一般来说一个数据库标的字段对应一个类的属性，这也符合一般开发人员的思维模式，使他们很容易接受而且灵活的运用。一般的持久化工具都对此有强大的代码生成支持。这种方法的缺点就是业务开发人员必须数据数据库。而且总会误导业务开发人员将数据库中的表和具体的业务仅仅相连，业务对象在某种程度上很容易被架空。从而失去分层的意思。这种方法要运用的好数据库设计便变的极为重要，数据库设计者必须不仅熟练数据库设计而且要深刻理解业务。在应对需求变更方面，这种方式也显得有些无力。因为业务逻辑本身的复杂程度，不可能直接全部依靠生成的业务类代码。再要从数据库直接生成界面，那必然还需要在做大量的代码工作，用友UAP提供了这种机制，但我觉得他的界面在很难在被自定义。

    以业务流程为主体展开设计，则业务对象就是主体。我们可以编写可视化的业务对象生成工具，或者直接用VS提供的类设计器，或者运用代码段来减少代码的输入。因为业务开发人员必须了解业务，所以对于设计业务类来说就是他们主要要做的事情。这样平台可以根据业务类和指定的数据源自动的生成数据库，以及数据库中的表。根据类与类之间的从属关系生成数据库的主外键关系。运用类的特性(attribute)和属性(property)的特性(attribute)或者是用配置文件来制定类实例的各种界面视图，从而提供与业务类直接生成界面的机制。为了不使灵活性除了平台提供的常用视图外，用户还可以自定义UI模版。以业务对象为主体的设计最大的缺点就是业务人员完全失去了对数据库的控制，对于极其特殊的需求来说，如果平台不能给予一个良好的制止的话，可能是开发人员陷入僵局。而且对于报表的开发，不能完全使用数据库本身所提供的强大的功能支持，对于平台开发者来说提供一套自动的生成控制机制也不是一件易事，平台开发难度大大增加。XAF便是这样设计的，很强大，而且他所做的已远远超出了我所能想象的。

   最后是以界面为主体的设计。原型设计法便是以这种思路出发，这种方式最容易和用户进行沟通也是用户最能理解的一种方式。但对于开发一个平台来说我真暂时想不出要怎么运用它。传说中这样描写。

//平台提供一种机制，界面设计者利用平台工具绘制出用户界面。
//和业务开发人员协作，运用平台工具，为每一个页面控件
//的属性设置具体的值。然后根据平台模块配置管理工具配置页面上各种动作的具体控制类。

不好意思这个我还真没想过，刚才想了一下怎么让平台根据界面设计者做的界面直接生成数据库，以及业务控制代码。也许可以某种强大的控件。

 

    今天先到这里，随着我的进一步的分析，在我们的思维完全发散以及取舍求证之后，我们不久就开始考虑框架层次的功能要求，以及选取一种合适的架构，然后进一步完善我们的设计。思维本身凌乱、错字、错句在所难免。原生态的思维呈现给大家，希望得到您的意见。