110,538
社区成员
发帖
与我相关
我的任务
分享大家谈谈：你认为应用框架应该提供什么功能？AAF交流大会暨庆祝升星散分典礼正式开始...
CSDN刚成立就来看过。但是说实话，就来了那一次。后来没怎么来过，主要还是去SourceForge CodeProject Fawcette Msdn 以及其它一些类似网站。
今年9月3日到这里注册主要是想借这里的人气为个人心血——AAF寻觅知音，同时也是在大半年忙碌之后稍事休整。但是，“不幸”的是，我发现CSDN的大多数同学们更关注特别具体的问题以及相关代码。没有办法啊，只好赤膊上阵回答问题吸引注意力。这时候，才恍然发现自己的一个绿色星星实在不好看啊，同学们都把那叫KC。不尽的羞耻啊，所以决定要赶紧挣颗红灿灿的星星。大约从10月13日起，我左擎苍右牵黄，开始了轰轰烈烈的挣分运动。经过整整两周的血战，到今天中午，顺利完成升星任务。
今天开始，本人准备分几次散尽注册以来未曾用过的所有分数（共计485分）。另外，本人的所有积分，均来自回答素不相识者的提问，分分干净，也算是对CSDN社区作出了一点贡献。今天之后，本人精力将放在其它地方，偶尔来CSDN可能主要也是维护个人blog。因此，对AAF或者应用框架有兴趣的朋友可以到http://blog.csdn.net/aafshzj与本人交流。
当然，本篇的主旨还是希望大家就“你认为应用框架应该提供什么功能？”这一话题展开讨论。普通跟顶者也有分，发言结合实际言之有物者，则会多多加分予以鼓励。
另外，有兴趣的朋友也可以到我的blog看看，如果能提出针对AAF的实际问题的，也会酌情加分。
本人博客：http://blog.csdn.net/aafshzj
今年9月3日到这里注册主要是想借这里的人气为个人心血——AAF寻觅知音，同时也是在大半年忙碌之后稍事休整。但是，“不幸”的是，我发现CSDN的大多数同学们更关注特别具体的问题以及相关代码。没有办法啊，只好赤膊上阵回答问题吸引注意力。这时候，才恍然发现自己的一个绿色星星实在不好看啊，同学们都把那叫KC。不尽的羞耻啊，所以决定要赶紧挣颗红灿灿的星星。大约从10月13日起，我左擎苍右牵黄，开始了轰轰烈烈的挣分运动。经过整整两周的血战，到今天中午，顺利完成升星任务。
今天开始，本人准备分几次散尽注册以来未曾用过的所有分数（共计485分）。另外，本人的所有积分，均来自回答素不相识者的提问，分分干净，也算是对CSDN社区作出了一点贡献。今天之后，本人精力将放在其它地方，偶尔来CSDN可能主要也是维护个人blog。因此，对AAF或者应用框架有兴趣的朋友可以到http://blog.csdn.net/aafshzj与本人交流。
当然，本篇的主旨还是希望大家就“你认为应用框架应该提供什么功能？”这一话题展开讨论。普通跟顶者也有分，发言结合实际言之有物者，则会多多加分予以鼓励。
另外，有兴趣的朋友也可以到我的blog看看，如果能提出针对AAF的实际问题的，也会酌情加分。
本人博客：http://blog.csdn.net/aafshzj
...全文
请发表友善的回复…
发表回复
自然框架 2006-11-01
- 打赏
- 举报
其实我也在弄一个自己的架构，知识还很不易用，只是自己用着方便，开发效率很快。
我说的那几点是一个概括性的目标，具体上嘛 就是 baseyueliang(baseyueliang) 说的了。
一个架构最主要的就是要处理好 添加、修改、删除、查询（如果是b/s的话还要加上一个分页显示数据），这几样。这些不是重点，但却是一个基础！
另外就是业务逻辑，控制数据的“流动”。
最后是显示。
呵呵。
我的想法和搂主的是比较很不一样的，因为我不是用的面向对象的。
我说的那几点是一个概括性的目标，具体上嘛 就是 baseyueliang(baseyueliang) 说的了。
一个架构最主要的就是要处理好 添加、修改、删除、查询（如果是b/s的话还要加上一个分页显示数据），这几样。这些不是重点，但却是一个基础！
另外就是业务逻辑，控制数据的“流动”。
最后是显示。
呵呵。
我的想法和搂主的是比较很不一样的，因为我不是用的面向对象的。
yggpc 2006-10-31
- 打赏
- 举报
看一看。
aafshzj 2006-10-31
- 打赏
- 举报
好了，估计也没有更多想法了，结贴。
aafshzj 2006-10-30
- 打赏
- 举报
baseyueliang(baseyueliang) 说得不错
继续...
继续...
aafshzj 2006-10-30
- 打赏
- 举报
起来~
iuhxq 2006-10-28
- 打赏
- 举报
关注一下，有时间看看
DePaul 2006-10-28
- 打赏
- 举报
jf
股神 2006-10-28
- 打赏
- 举报
jf
aafshzj 2006-10-28
- 打赏
- 举报
jyk(喜欢编程。和气生财。共同提高。共同进步) :
1、开发效率一定要高，否则不适应中国的行情。
2、效率不能太低了。项目上线后，运行起来跟蜗牛式的也是不行的。
3、使用方便。使用了你的架构，比不使用还麻烦的话，谁会去用呀！
4、内部结构要简单，要便于扩展。
5、应用范围有两种方向：一是全面，另一个就是专一了。
==========================================================
jyk讲得很好，下面是我的一点看法。
1）框架是为了提高开发效率的，否则确实没人会用。
2）一个基于框架开发的系统不一定在各种性能指标上超过不使用框架开发的系统，但至少要在总体性能上，使得不使用框架开发的系统需要付出多得多的代价，才可能达到类似的水准。
3）关键在于对外服务接口的设计，既要提供一些相对复杂的接口/方法以便用户使用一些高级特性解决高级问题，也要提供简化接口/方法使得对高级特性暂时没什么要求的用户能够非常简易地使用框架。归根结底，就是给用户提供更多的选择，而不是对用户强加更多的限制。
4）内部结构需要在能够满足提供所有特性以及预留扩展基础上的简单。内部的结构有时候可能让人从外初看起来很复杂，但是必须是解决所有要解决的问题的前提下最简单或者极简单的一种。
5）在框架应用范围广度和深度的选择上，确实常常各有侧重点。就我个人而言，我觉得框架在应用范围上既要有一定的宽度，也要有一定的深度。因为，如果宽度太窄，应用面就太小，可能的应用范围就太有限；同时，如果深度不够，就没有不可替代性，最终也会失去意义。因此，我的基本策略是侧重应用中的一些普遍共性，做深做细，并且不断通过抽象的抽象从其它不同中提炼出更多的相同。
欢迎经常交流。 ^_^
1、开发效率一定要高，否则不适应中国的行情。
2、效率不能太低了。项目上线后，运行起来跟蜗牛式的也是不行的。
3、使用方便。使用了你的架构，比不使用还麻烦的话，谁会去用呀！
4、内部结构要简单，要便于扩展。
5、应用范围有两种方向：一是全面，另一个就是专一了。
==========================================================
jyk讲得很好，下面是我的一点看法。
1）框架是为了提高开发效率的，否则确实没人会用。
2）一个基于框架开发的系统不一定在各种性能指标上超过不使用框架开发的系统，但至少要在总体性能上，使得不使用框架开发的系统需要付出多得多的代价，才可能达到类似的水准。
3）关键在于对外服务接口的设计，既要提供一些相对复杂的接口/方法以便用户使用一些高级特性解决高级问题，也要提供简化接口/方法使得对高级特性暂时没什么要求的用户能够非常简易地使用框架。归根结底，就是给用户提供更多的选择，而不是对用户强加更多的限制。
4）内部结构需要在能够满足提供所有特性以及预留扩展基础上的简单。内部的结构有时候可能让人从外初看起来很复杂，但是必须是解决所有要解决的问题的前提下最简单或者极简单的一种。
5）在框架应用范围广度和深度的选择上，确实常常各有侧重点。就我个人而言，我觉得框架在应用范围上既要有一定的宽度，也要有一定的深度。因为，如果宽度太窄，应用面就太小，可能的应用范围就太有限；同时，如果深度不够，就没有不可替代性，最终也会失去意义。因此，我的基本策略是侧重应用中的一些普遍共性，做深做细，并且不断通过抽象的抽象从其它不同中提炼出更多的相同。
欢迎经常交流。 ^_^
JasonHeung 2006-10-28
- 打赏
- 举报
减少写代码的部分就等于减少出错误的机会！这世界上大部分应用都有现成的代码，关键是如何能将其组合起来，实现一个完整的系统！可能需要对这些代码本身的编写结构提供一种标准和对外的接口，所谓Com,Com+,ActiveX是远远不足的，XML也还粗躁，关键是组件能根据一定的条件描述条件，自动连接、交换数据、协作计算！
yeerh 2006-10-28
- 打赏
- 举报
接分
自然框架 2006-10-28
- 打赏
- 举报
1、开发效率一定要高，否则不适应中国的行情。
2、效率不能太低了。项目上线后，运行起来跟蜗牛式的也是不行的。
3、使用方便。使用了你的架构，比不使用还麻烦的话，谁会去用呀！
4、内部结构要简单，要便于扩展。
5、应用范围有两种方向：一是全面，另一个就是专一了。
ps:我也在研究自己的一种架构，有空没空多联系！
2、效率不能太低了。项目上线后，运行起来跟蜗牛式的也是不行的。
3、使用方便。使用了你的架构，比不使用还麻烦的话，谁会去用呀！
4、内部结构要简单，要便于扩展。
5、应用范围有两种方向：一是全面，另一个就是专一了。
ps:我也在研究自己的一种架构，有空没空多联系！
jacobwc 2006-10-28
- 打赏
- 举报
简单好像和高效矛盾了的
简单的框架代码肯定复杂
高效了算法肯定也复杂
简单的框架代码肯定复杂
高效了算法肯定也复杂
aafshzj 2006-10-28
- 打赏
- 举报
在你需要开发速度时，你提供各种封装好的方法，然你快速(但并不高效)的开发出项目
在你根据兴趣开发时，开放一切后台，让你任意发挥~~~
YY中...
=================================================
呵呵，想法不错。
但是也面对挑战。封装不用讲了，封装好的框架，如果设计及性能等都比较好的话，肯定可以大幅度提高开发生产力。但是，开放后台除了各种版权和其它非技术问题之外，最好的方式也只是供你借鉴，一旦你开始自己“发挥”，你就很难再享受今后升级的好处，除非你是根据框架提供的扩展接口进行扩展和修改。但是，在这种状况下，似乎内部代码是否开放又变得不重要。
从我个人的感觉，开放的代码借鉴意义更大，真正的修改最好还是向框架核心开发小组提出建议，并由其进行改进。用户在个性化开发时，最好还是按照开发的接口和“协议”进行开发。
baseyueliang 2006-10-28
- 打赏
- 举报
对于数据库应用系统来说其本质就是增删改差这四种操作的各种组合，我们作为这种系统的开发者，就是插上富有想象的翅膀，对客户的业务需求mapping出各种操作的组合，虽然各个企业的需求有所不同，即这四种操作的组合方式可能有所不同，但是其每种组合的子操作是类似的，如果不复用已有的代码或者不抽象出公共的方法，将造成大量的重复开发。而对于数据库应用系统的框架，其任务不言而喻，那就是最大限度的减少这种重复行为，框架的抽象力度和可重用程度也决定了是否适用哪些应用业务，或者不适用哪些应用业务。比如某个框架号称开发一个系统只用写10行应用代码，而很难用来开发作者提供的示例系统以外的其他系统，有如另外一个框架号称市面上的业务可以通杀，而用其开发一个具体的系统还要写大量的代码，和用原生开发只少了10％的代码量，何况很多开发方自己都或多或少积累了各种可复用组建或方法。还有框架升级后保持向旧系统兼容是个很大的问题，最后极有可能演化成一个旁然大物，如恐龙，最终死亡（被其他框架替代）。
自然框架 2006-10-28
- 打赏
- 举报
收藏
aafshzj 2006-10-28
- 打赏
- 举报
yan63言之有物：
不错的观点，也代表了很多人的意见。但是彻底开源，尤其是在中国，我几乎看不到商业成功的希望。因此，我最终可能会采取半开源的方式。其实是不是一定要源代码有时候还是取决于信誉和说服力，毕竟我们使用的很多软件，哪怕是开源的，也还是基于很多非开源的实现。
欢迎你来我的blog交流，也欢迎大家来各抒己见。
不错的观点，也代表了很多人的意见。但是彻底开源，尤其是在中国，我几乎看不到商业成功的希望。因此，我最终可能会采取半开源的方式。其实是不是一定要源代码有时候还是取决于信誉和说服力，毕竟我们使用的很多软件，哪怕是开源的，也还是基于很多非开源的实现。
欢迎你来我的blog交流，也欢迎大家来各抒己见。
yan63 2006-10-28
- 打赏
- 举报
......一旦你开始自己“发挥”，你就很难再享受今后升级的好处，除非你是根据框架提供的扩展接口进行扩展和修改。但是，在这种状况下，似乎内部代码是否开放又变得不重要。
从我个人的感觉，开放的代码借鉴意义更大，真正的修改最好还是向框架核心开发小组提出建议，并由其进行改进。用户在个性化开发时，最好还是按照开发的接口和“协议”进行开发。
--------------------------------------
多数情况下，我不会拿reflector去查看.net实现，在实际的项目中却倾向于使用源代码开放的的block,对别人的做法也不一定都研究得很深，只不过图一个放心，如果有问题，一定在自己的可控制范围内，而不一定要指望作者的反馈和版本升级，所以文档，代码和测试用例我觉得是一个好的框架不可缺少的要素，使用者也可以向作者提交，当然决定权在作者，这样子或许是个好的方法，一点不成熟的看法
无论如何，对楼主的工作致以敬意。希望有时间能在blog上向楼主讨教。
nice work!
从我个人的感觉，开放的代码借鉴意义更大，真正的修改最好还是向框架核心开发小组提出建议，并由其进行改进。用户在个性化开发时，最好还是按照开发的接口和“协议”进行开发。
--------------------------------------
多数情况下，我不会拿reflector去查看.net实现，在实际的项目中却倾向于使用源代码开放的的block,对别人的做法也不一定都研究得很深，只不过图一个放心，如果有问题，一定在自己的可控制范围内，而不一定要指望作者的反馈和版本升级，所以文档，代码和测试用例我觉得是一个好的框架不可缺少的要素，使用者也可以向作者提交，当然决定权在作者，这样子或许是个好的方法，一点不成熟的看法
无论如何，对楼主的工作致以敬意。希望有时间能在blog上向楼主讨教。
nice work!
aafshzj 2006-10-28
- 打赏
- 举报
JasonHeung(拥有一切不过就这样笑着哭) 说得不错。
“Com,Com+,ActiveX是远远不足的，XML也还粗躁”，这些更象基本的沙石、砖块。在实际开发工作中，在真正的第二线，我们需要更大一些的building block以及强大的组装引擎，对一些可以组装的预制件进行组装。其中一些是非常通用而灵活的，另外一些则是定制开发的，我们需要一种方式将它们很好地结合起来。
“Com,Com+,ActiveX是远远不足的，XML也还粗躁”，这些更象基本的沙石、砖块。在实际开发工作中，在真正的第二线，我们需要更大一些的building block以及强大的组装引擎，对一些可以组装的预制件进行组装。其中一些是非常通用而灵活的，另外一些则是定制开发的，我们需要一种方式将它们很好地结合起来。
shalen520 2006-10-27
- 打赏
- 举报
关注下
加载更多回复（25）
