|
|
|
|
EOS小析之一 从WEB Framework入手
发布时间:2005-08-26 00:00:00 作者:cservice 出处:goComDevCenter 语言:中文 阅读次数:1170次 |
| Java社区一直是最活跃的社区，最新的软件方法、模式、理念基本上都以Java作为
第一实现。众所周知J2EE之所以受到开发者厚爱其中一个最大的原因是开放，而其
开放的最大原因是大部分情况下只是JCP制定JSR，而实现由社群去完成。于是出现
了一个没有一站式服务的厂商、工具、方法及模式的支持（相对应的.Net却是由M$
提供了一站式的服务）。对于各个J2EE组件间的粘接及方法级（语言级）的解偶是
J2EE成为工业级应用平台以来开发者一直在研究与实践的，研究与实践的直接成果
之一是出现了非常多的框架产品和支持理论，有WEB层的、有业务层的、有持久层
的等等，也造就了Java社区的繁荣昌盛。
在MVC经典架构的支持下，无可救药的涌现出了一大堆WEB层的支持框架，其中最为
流传也就是Struts、Spring 和 WebWork，都是基于Request技术的；而Struts因出
现的时间较早且成熟度高有先入为主的嫌疑，较大规模的占据了Web框架应用市
场；但是该死的Action Form却总是在阻碍开发者的自由，虽然后来有了Dynamic
Action Form，但也应用得非常生涩。另外Struts的跳转配置虽然很灵活，但是对
于配置文件的处理却是难受的很；其实这是所有基于语言级耦合框架的共同缺点。
EOS的出现很大程度上解决了耦合问题，当我第一次了解到其核心思想XML数据总线
时，我就知道完了，EOS解决了以上框架都没有解决的问题。XML技术在数据处理上
先天的优势，类型无关性、实时可扩展性、类SQL的可查询性、平台无关性等决定
了其在数据交换领域的绝对地位，而Struts、 Spring、WebWork等都没有将其应用
在业务数据交换领域，只是用它做了非常有限的工作：配置相关。
我们认为业务数据在持久化容器（数据库或本地文件等存储设备）中可以是无类型
的即非状态的，但是在运行生命周期中却是有状态（数据的自我描述性及数据的作
用域问题）；不可避免的我们在实际的开发工作中受阻了，对于客户提出的业务数
据扩展总是苦不堪言，对于客户界面及功能扩展要求也是推推脱脱，把销售人员在
客人面前建立的光辉形彻底颠覆了，从此在 [改数据表 --> 改Bean文件 --> 改
DTO文件 --> 改Action Form --> 改JSP映像 --> 重新编译 --> 重新部署] 的过
程中来回奔波，直至累死或被客人骂死；开发人员的关注点也开始发生变化了，由
关注技术转入关注业务，做过两个项目后都成为了业务专家，技术却落下了一大
段，于是开发者开始了停滞不前，技术上的迷茫带来了对自身定位的怀疑，原来IT
精英的梦想死在了项目开始后的第二个年头，行业里也开始流行了一句口号 “我们
靠意志生活”；是的我们随需应变的能力太差了，我们始终跟着客户在走，我们无
法应附自如；如果不能随需应变，那又怎能多快好省呢？呵呵，扯远了。
EOS在MVC基础上，采用XML作为核心变换工具，完全实现业务数据总线化，对各组
件实现数据级耦合，这是软件开发技术的一大进步；EOS完成了控制软件与业务数
据相对无关性工作，使开发者可以专注于表现层的精美等工作，而不必要关心客户
的数据流程及数据结构的改变，基本实现随需应变。
通过XML数据总线的应用，实现业务数据级耦合更贴近我们需要模拟的现实业务，
这是EOS的构架观。
哈哈，接下来如果有时间的话，打算分析一下EOS的持久化框架。
|
|
| 声明：本栏目转载文字、造型、样式、图形及程序如有来自网络，版权归原作者或首发媒体所有，欢迎任何个人访问或者转载，若有作者及出处有误，请来信说明，我们将及时更正。 |
|
