锁定老帖子 主题:解决侵入的根本方法讨论
该帖已经被评为精华帖
|
|
---|---|
作者 | 正文 |
发表时间:2006-12-26
我觉得最关键是提高生产率。而不是泛泛的讨论一些设计理论。
如果侵入能够大幅提高效率,减小代码量,又有一定的扩展性,也是欢迎的。 框架的移植、数据库的移植、应用服务器的移植,只是讨论多于实践,有多少人在闲着没事,移过来移过去。 侵入性并不一定是坏事。 |
|
返回顶楼 | |
发表时间:2006-12-26
dongbin 写道 太虚了,给点例子好么
虚是正常的,从标题中的就已经给出定位了。 对一个后验系统,讨论它的根本解决办法,本身就是一件虚的事情。 不过ajoo的类比很有意思,形象! |
|
返回顶楼 | |
发表时间:2006-12-26
看了楼上的对话,比较认同ajoo的观点。其实楼主在理解侵入上出现了一个模糊的地方,楼主究竟是想讨论框架对应用程序的侵入,需要迫使应用程序遵守框架的约束?还是说应用程序需要能对框架进行侵入式的扩展,从而能够定制框架所实现的功能?
ajoo看到的是前点,所以自然无法认同你的观点。而楼主本身对两者定义的模糊,才有了希望主动侵入的观点。 另外,也需要说明一点,对于规范和协议的遵守,并非所谓的侵入(这种规范自然包括Javabean)。其实我想楼主的所谓的侵入应该是应用程序组件级的强制依赖。当你所开发的系统强制依赖于某个框架组件,并且不能进行轻松并有效的替换或者调节时,那么它就对你的系统形成了侵入。 (也简单说明一点,我至今并不认为EJB是种侵入。其实ajoo也表述了类似的思想,在框架集成的地方并不能称为侵入。) |
|
返回顶楼 | |
发表时间:2006-12-28
感觉 "侵入" 可能是到了 框架 时代, 对 链接库 时代的 "依赖" 概念的一个升华结果.
链接库 给应用的只有一堆白纸黑字写好的接口签名和或多或少的说明文档, 应用按照这些库期望的先后顺序和逻辑结构, 通过调用的方式向库代码传递参数和执行控制权, 并获得它们承诺的结果. 通过 链接库 的方式使用第三方软件功能, 应用程序在执行控制上占有绝对主动权, 但在那些功能的实现和定制上却处于绝对的被动地位, 只能通过该库所提供的定制接口调用来显式的定制. 但是到了框架时代应用程序和第三方功能之间的关系发生了微妙的变化, 应用 和 框架 之间变成了协作关系, 框架实现的逻辑 不再像 链接库的逻辑 那样是预先开发好以后就一成不变的了, 而是拥有了对 应用逻辑 的适应性, 能够通过 定义接口规范 以外的一些途径, 比如 约定, 框架基类/接口, 配置文件, Annotation 等等进行为了完成应用目标功能为目的的接触和融合. 这些变化也为目前的 IoC 思维大行其道提供了可能的舞台. 从此也就诞生了 "侵入" 的概念, 我感觉可以大致理解为 "在软件组件接合方式上, 本无必要或者过份的要求" 的意思. 而目前的局势下还没有轮到 应用 可以在语法上给 框架 提要求的份儿, 所以 "侵入" 一般是讨论 框架 对 应用 的非份要求. 但是在编程要求方面, 框架对应用的这种 单边关系 在下一代软件开发体系中是有望改变的, 我的信心来源是 元编程 理论和实践的日渐成熟. 而理想的结果就是 应用 可以通过公认的声明方式提出自己对 框架 的要求, 而各种框架也能够在成熟的公共知识基础上找到简易的方式来解释和实现 应用 的要求. 这里去实现这些 框架 的简易程度是关键因素, 因为这时对框架的丰富性要求也大增, 比如同一套 应用需求声明, 这时已经不仅仅是须要有至少一个框架能支持它的部署和运行就够了, 其他比如在单元测试方面, 就需要另一套框架逻辑的支持. 在不同平台上对相同应用需求的满足也需要它们各自提供的框架能够容易实现. 那时候的框架也许会另有其名, 它们对应用需求的适应性比目前的 框架 是要更提高了一个级别, 如果以我一直在思考研究的 面向能力编程 的思想来命名, 可能会称其为 能力提供者 (Capability Provider). |
|
返回顶楼 | |
发表时间:2007-03-13
值得关注,学到不少东西
![]() |
|
返回顶楼 | |
发表时间:2007-03-13
无侵入性框架,应该是,"你需要我的帮助?OK,那你什么都不用做,我给你提供.但是,你至少要告诉我,你需要什么?或者用来做什么?".这种完全服务性质的框架.关键就在于,这种"你至少要告诉我",这个告知的方式是怎样的.
很多是用引入框架的类或接口,稍微人性化点的则是使用xml或者其他配置文件(并不认为使用配置文件是一种侵入,侵入应该是在代码级别). 提供某种或某类服务的框架,不应该强制应用遵循或者执行某种条件来进行交换. |
|
返回顶楼 | |
发表时间:2007-03-13
无侵入就是把所有的单元全独立(一进口一出口)
但是如果所有的单元全独立管理又无法管理 好管理了又无法重用..... 根本方法是不重用 只要重用就得侵入 少侵入就扩大了适用面 但减少了重用可能 |
|
返回顶楼 | |
发表时间:2007-05-08
如果框架从相对路径方面着手,会不会在侵入性方面有一点突破呢?
比如 某框架对某种定义的异常有特殊处理,那么我们的应用代码如果需要相关的功能就要被框架侵入。 那如果约定对相对路径:web-inf/classes/exception/*****下的所有*.class 自动处理此异常,也许在侵入上会有一点突破,不过还是有 xml配置的另一种说法而已。 当然只是想看看大家是怎么想的 ? |
|
返回顶楼 | |
发表时间:2007-05-08
越来越像ror了
|
|
返回顶楼 | |