平台现在无疑已经是一个用滥的概念。先来看看业务平台的定义：是为企业提供的一个可快速开发的、稳定的、成熟的业务基础开发平台。实际上在一个技术人员的眼里，平台=类springside的开发框架+一套组织机构+和组织机构相适应的一套权限系统+门户+信息资源库+工作流引擎+一些通用的业务模块。因为一直做关于所谓业务平台的开发，有过困惑也有思考，这里说说自己对于平台的一些想法，也希望大家多多拍砖。我认为一个好的业务平台应该做到下面的几点：
1、业务性。
   这个问题我曾经和胡长城有过很长时间的争论。最后我得承认胡兄的正确性：业务确实是一个平台的根本。一个业务平台如果不满足业务的需求，那么它存在的意义就值得怀疑。一个很简单的例子，协同办公中不可缺少的发文管理，正文需要用到电子签章，业务中有这个需求，平台不支持，那么这个平台就不是个好的业务平台。
2、易用性
   业务平台不是面对最终用户的，它需要做二次开发。这样平台对程序员的友好性就相当重要，毕竟平台的使用者还是程序员。
   基础代码生成是必要的，不管你采用何种方式，是根据已有表格来生成模型和相应代码还是先画出模型再来生成表格和相应代码（所谓的MDA）。平台的代码结构最好能够和IDE有个良好的结合，因为项目的开发往往是几个程序员协作的过程，平台对代码开发的支持不可能做到IDE的水平。最好的方式是生成的代码自动在IDE里有着清晰的结构，在IDE里编辑、测试自己的代码，然后自动发布到平台相应目录中，启动平台，代码运行成功。eclipse插件是个很好的选择。
   良好的API的支持，开发中不可避免的会与平台已有的组织机构模型和权限系统交互，这样良好的、封装清晰的API支持就很重要。
   页面组件的支持。往往有时候凌乱的WEB页面最让人头疼。对常用的一些页面元素可以用标签或是AJAX做进一步的封装。比如树组件、弹出层组件、分页组件等等。与这些相比，一些业务页面组件的封装也很重要。比如需要在页面选择用户，直接封装出一个用户选择组件，而不用开发人员在页面用弹出层+用户树自己再去组装。再比如说发文中的签批意见，可以用AJAX直接封装到页面里，不用用户自己调用相应API。意思就是让用户开发尽量简单，把工作从代码里尽量推到页面上去。
3、模块化。
   尽管这个或类似概念（比如说组件、构件）一再被平台厂家们提及，我对实际的实现一直报怀疑的态度。实际的实现往往是对模块的一个模拟。这里的模块实际上是对代码做出的一种人为上的区分，所谓的模块配置，更直接一点就是页面URL的配置。与代码行为无关，与运行期管理更没关。
4、可扩展性
   这个暂且不说，很大的一个话题。
5、前瞻性。
   一个优秀的平台凭什么和别人不同，一个很重要的一点就是平台的前瞻性。一句话，就是要有别人没有的东西。个人非常看好未来对业务整合的需求，遗留的业务系统+国外大厂商的概念轰炸让客户开口就是业务整合、BPM。是时候不再忽悠而是做点实际的东西了。
可以说，业务性+易用性在现阶段就是一个很好的平台了。如果再有些前瞻性的东西（注意：不是口头上！）这个平台应该说很优秀了。至于模块化、可扩展性，想想，现在只能说忽悠了。


http://www.blogjava.net/ronghao 荣浩原创，转载请注明出处：）