| 作者 |
内容 |
| mjt1975 |
 有没有研究领域应用框架的哥们？
兄弟论文研究领域框架，欢迎感兴趣的朋友共同研究、交流！
请mail :mjt_hhu@263.net |
| 01/09/04 12:38 |
酷帖！ 臭帖！ 回复 |
| 酷帖评价： 臭帖评价： |
| 返回页首 |
|
| potian |
回复:
有没有研究领域应用框架的哥们？
我的Taoerp.org就是为了研究框架的。 |
| 01/09/04 12:57 |
酷帖！ 臭帖！ 回复 |
| 酷帖评价： 臭帖评价： |
| 返回页首 |
|
| fqnewman |
 我在干一些此类事情
|
| 01/09/04 13:51 |
酷帖！ 臭帖！ 回复 |
| 酷帖评价： 臭帖评价： |
| 返回页首 |
|
| gzly2000 |
现在有很多种应用框架，不知你要研究那种？
|
| 01/09/04 14:26 |
酷帖！ 臭帖！ 回复 |
| 酷帖评价： 臭帖评价： |
| 返回页首 |
|
| potian |
回复:
现在有很多种应用框架，不知你要研究那种？
我实在不知道有多少实际能够使用的应用框架。我看到过的包括ralphon的财务框架，HotDraw/Drawlet，但这些框架都太局限了。
IBM的WSBC是不错的，但是首先,他和IBM webSphere结合太紧密，其次，它的源代码是不开放的。
我们将实现的框架包括以下内容：
Role
Party-accountability
dynamic properties
Business Rule framework(expert system)
contract
time
quantity/currency
value object
框架的体系结构可以参见我主页上的文章，主要分为service
provider和business object两个层次，虽然框架最后将应用到J2EE平台，但我们使用包装的方式可以用该框架构建非j2EE系统（类似于Sanfransisco).
框架分为抽象层，元素库（直接可以使用的元素），框架GUI构建和配置工具，脚本支持。
该框架是整个ERPAO的业务底层，我们将使用该框架构建一个一流的ERP系统。
|
| 01/09/04 16:16 |
酷帖！ 臭帖！ 回复 |
| 酷帖评价： 臭帖评价： |
| 返回页首 |
|
| huangcy |
回复:
有没有研究领域应用框架的哥们？
我觉得涉及某个行业得框架是不是容易应用一点，特别是那些已经规范化
得行业。 |
| 01/09/04 19:48 |
酷帖！ 臭帖！ 回复 |
| 酷帖评价： 臭帖评价： |
| 返回页首 |
|
| aspring |
呵呵，http://www.Taoerp.org怎么连接不上啊？
|
| 01/09/05 12:14 |
酷帖！ 臭帖！ 回复 |
| 酷帖评价： 臭帖评价： |
| 返回页首 |
|
| potian |
Sorry!
www.erptao.org
|
| 01/09/05 12:37 |
酷帖！ 臭帖！ 回复 |
| 酷帖评价： 臭帖评价： |
| 返回页首 |
|
| jordan-gxj |
 回复:
我用应用框架开发过实际应用程序（已在使用）！
我们的应用框架主要包括：
1。通用的数据事务处理；
2。通用的系统字典处理；
3。通用的系统出错处理机制；
4。界面自动生成；
5。菜单自动生成； |
| 01/09/06 11:59 |
酷帖！ 臭帖！ 回复 |
| 酷帖评价： 臭帖评价： |
| 返回页首 |
|
| aspring |
 能不能透露一点细节哦？
哈哈，最好能透露一点细节哦，比如动态属性，对象数据存储。。。
谢谢。 |
| 01/09/06 12:46 |
酷帖！ 臭帖！ 回复 |
| 酷帖评价： 臭帖评价： |
| 返回页首 |
|
| potian |
应用框架辨别
我不是很清楚你对框架的理解是什么，但从你列出的内容来看，你这些功能不是框架。如果有框架的话，你的这些东西也是框架的最外面一层。
国内曾经非常流行的生成器就是你所说的这个样子，能够自己定义数据表，定义查询，定义出错，甚至定义脚本。当然界面也使能够定义的。
我所在的公司1994年开始开发这样一个东西，现在大概有50几家单位在用，那么这样一个生成器能不能算是框架呢？我持否定态度。
框架是对设计的可重用，框架（面向对象）是一系列抽象类的组合。如果只考虑框架的核心，那么只是抽象类的集合，它不能完成任何工作。所以，一般来说，会按照框架白箱实现基本元素库。譬如TBBC框架将实现Role
+ party模式。是对所有可能出现的人，组织以及它们之间关系的一个设计的抽象实现。如果只停留在这一步上，那么使用框架是极为困难的。
框架是可重用的，可重用的含义是当你需要扩展框架的设计时，你可以重用它达到更大程度的框架，同时也意味着不同的应用框架通过Adpter可以合成更大的框架，框架的重用方式分为两种：白箱和黑箱。
使用白箱重用是框架在建立抽象以后的第一步，据我前面的例子,我使用Role+Party去实现很多person,company,group
company等等，这些元素是具体的，直接可以被用户代码所用的，也就是如果我使用框架去开发一个应用程序，这些元素可以被直接使用，当这些元素形成一定规模以后，我可能会建立元素库。白箱重用指重用的程序员需要了解框架内部的结构，使用继承进行重用。
有了元素库和框架抽象，下一步地重用就是黑箱重用。所谓的黑箱重用就是用户不需要知道框架的内部结果，直接使用框架提供的元素。上面的例子中，person
,company可以直接被使用，从而大大增强了系统的开发速度和稳定性。
黑箱重用和白箱重用是一个交替的过程，随着黑箱重用的不断深入，越来越多的设计（抽象）被提炼，最后使用白箱重用对框架进行扩展，理论上讲，这个过程将永远不会结束。
当元素库的积累到了一定程度以后，我们可能会使用一些GUI工具去自动生成元素的组合或者应用程序，这时候就是GUI
Builder了。这一块从严格意义上来讲并非框架的组成部分，但提供了对开发的强有力的支持，同样在这里可能需要脚本处理。
所以，你讲的对菜单、数据字典（从我的观点来讲，这些东西不应该在一个oo系统中出现）的GUI生成器，显然不是一个框架。我甚至可以推测，你既然定义数据字典，那么对这些数据的处理界面将和用户界面严格绑定在一起。你不会对也业务中的模型进行抽象和实现，在你的系统中，将没有任何一部分可以被以后的系统可重用。
但是，也许我说的是错的，你可能已经实现了我所讲的抽象、元素库，然后在这之上使用了GUI编辑器。
|
| 01/09/06 13:35 |
酷帖！ 臭帖！ 回复 |
酷帖评价： 臭帖评价： |
| 返回页首 |
|
| jambol |
 这位哥们说的有点意思了
我正在研究基于框架的业务管理系统（这个说法太笼统了些）
希望能在业务抽象及建模上交流交流 |
| 01/09/06 14:48 |
酷帖！ 臭帖！ 回复 |
| 酷帖评价： 臭帖评价： |
| 返回页首 |
|
| aspring |
回复:
应用框架辨别
按照RUP,一般ERP系统，或者说是信息管理系统包括下面几层：
1.顶层是应用程序层，它包括应用程序专用的服务。
2.下面一层是业务专用层，它包括在一些应用程序中使用的业务专用构件。
3.中间件层包括各个构件，例如 GUI
构建器、与数据库管理系统的接口、独立于平台的操4.作系统服务以及电子表格程序、图表编辑器等
OLE 构件。
4.底层是系统软件层，它包括操作系统、数据库、与特定硬件的接口等构件。
我是怎么理解的：系统软件层和中间件层都是其它厂商提供的，是一个软件开发时候的客观环境。整个系统是构架在这些客观环境之上的。
对照ERPTAO的模型看，Tao工具层和Tao应用程序层对应于这里的应用程序层。Tao业务元素层和Tao服务层属于业务专用层。基础结构层相当于系统环境，相当于中间件层和系统软件层。
按照层次理论，越是上层的东西，被重用的可能性就越小。所以我理解框架实际上是业务专用层。
GUI构造实际上有两种方式，一种方式是根据业务对象的属性自动生成GUI界面，另外一种方式是用户定义界面，然后程序根据用户的定义生成界面。
在第一种情况下，GUI构造器（负责自动根据业务对象属性生成界面）就是处于业务专用层的下层（比如Tao服务层）。在第二种情况下，GUI构造器（负责根据用户定义生成界面）同样处于业务专用层，而定义用户界面的这个工具就是处于应用程序层（比如Tao工具层）。
再考虑和数据库管理系统的接口，所有（至少大部分）业务对象是需要存储的，这里所说的业务对象当然是指应用程序可用的对象，比如病人等等。在这种架构下，这些业务对象实际上是由更小的对象来构成的，比如观察者，测量值啊什么的构成（参见Martin
Flower的《Application Facade》）。所以似乎需要一个Entity构造器，用来负责1.根据定义完成业务元素到业务对象的转化；2.业务对象（业务元素）的持久（数据库存取操作）。同样需要一个Entity定义的工具，Tao中称为Entity
Build.
jordan-gxj 兄的东西可能不是非常的OO，应该也有很多可以参考和借鉴的地方。potian
兄的方案中提到对象持久的内容比较少，不知道是怎么想的，很想听听你的意见。Hehe,：） |
| 01/09/07 11:35 |
酷帖！ 臭帖！ 回复 |
| 酷帖评价： 臭帖评价： |
| 返回页首 |
|
| potian |
回复:
应用框架辨别
我在不同的文章都曾经提到O/R mapping的问题，实际上，我自己是在delphi下实现的O/R
mapping套件。该存储层现在被我自己和两家其他的公司使用。我也在其他文章中说过delphi实现存储层的困难。
对Java存储层的研究是从学习castor开始的，castor实现了object的xml,rdbms等多种方法存储，ODMG兼容，支持OQL,功能非常强大。Sun
也提出了JDO的specification，大家可以好好研究一下。
象IBM的wsbc使用CMP，并且和webspere严密帮定，我就觉得很难使用。
要实现相对自动化的EJB存储，一种是象IBM的使用CMP，也就是该应用服务器提供的o/r
mapping工具，但这种方式的缺点是几乎没有一个应用服务器使用相同的映射定义，所以关于这一部分，几乎是不可移植的。又由于不同应用服务器所提供的o/r功能相差太大，几乎是完全重写。从我自己的erp项目来看，不但应该可以使用到大型的如IBM
webspere(Oracle的EJB container太差了），还应该让用户能够使用像jboss这样非常健壮的开源产品，所以IBM的方式我是持否定态度的。
另外一种方式是使用castor和cocobase这样的第三方O/R
mapping工具，我特别推荐的就是castor,一方面来讲功能非常强大，另一方面试他的源代码开放，如过需要移植的话，应当问题不大。现在我的组合是jboss+castor.
当然，随着JDO的不断完善，应当说BMP和CMP两种方式将最终融合在一起。预计马上就会有完全兼容JDO标准的O/R
mapping出现。
我曾经参加过一段时间的ozone OODBMS，发现问题还是很多，至少目前应用的可能性还不太大。所以没有继续下去，另一方面来讲，也是国内的形式所限，要专注于这方面可能在10年内是不会有回报的，而我并不是研究所的专业人员（也许等我生活好一点，我会专业从事研究），所以这方面我暂时决定不再深研。 |
| 01/09/08 22:02 |
酷帖！ 臭帖！ 回复 |
| 酷帖评价： 臭帖评价： |
| 返回页首 |
|
| aspring |
回复:
应用框架辨别
hehe,我对你用Delphi实现的的O/R mapping套件非常感兴趣，既然已经有你们公司和另外两家公司在用这个东西，应该已经比较稳定了，不知道你们有没有兴趣把这部分内容作为一个单独的产品出售？或者以其它的形式合作。
你的Mail地址是否有误，我的Mail被退回来了，如果感兴趣的话，是否可以联系我？springair@263.net |
| 01/09/11 10:02 |
酷帖！ 臭帖！ 回复 |
| 酷帖评价： 臭帖评价： |
| 返回页首 |
|
| aspring |
 救命啊...
大哥,真的是帮帮忙阿,否则小弟就要失业拉....为这个鬼东西,公司已经走了很多了,现在就剩没几个人撑局面了.而且似乎对你们公司也没有什么坏处.包装以后不一定只卖我们一家的,说不定还有很多人想要呢,就象Cell一样.有些功能我们可以不要.我们不要完美,我们只要求一个是动态属性.另外一个性能不是太差就可以拉.
Help!!!!!!! |
| 01/09/13 13:15 |
酷帖！ 臭帖！ 回复 |
| 酷帖评价： 臭帖评价： |
| 返回页首 |
|
| potian |
回复:
救命啊...
aspring,给我去信，shiyiying@hotmail.com,我们仔细聊聊 |
| 01/09/13 13:36 |
酷帖！ 臭帖！ 回复 |
| 酷帖评价： 臭帖评价： |
| 返回页首 |
|
| aspring |
回复:
救命啊...
我要吐血了，你的Mail有没有错误阿？我的Mail怎么又被退回来了？
QQ吧：507141 |
| 01/09/17 15:54 |
酷帖！ 臭帖！ 回复 |
| 酷帖评价： 臭帖评价： |
| 返回页首 |
|
