|
|
导航: |
论坛 -> 开源项目
斑竹:joki,ralf_jones |
|
作者: |
|
2004/5/7 12:12:10 |
标题: |
答 canicula 的"几个疑问" |
浏览:2805 |
|
加入我的收藏 |
楼主: |
1,最新的版本调试不能通过,有几个以pp开头的单元找不到
这是ReportBuilder 7。
2,从单元的名方法上看,是使用d7,d6就难兼容了,d6+sp2还是很稳定的,用的人也比较多
开始并未打算用于D7之前的版本,不过在Beta版(现在是Alpha版)中我已经修正了这个问题使之可以用于D6。
3,框架正在分析,不过是基于以前版本的
之前的SmallStruct2与现在的版本有很多不同
4,建议斑竹还是写些东西,比较清晰的传达你的设计思想,这是讨论的基础,不要到头来,重新构造你的类体系。而讨论也应该基于文字,而不是代码。等大家达到某种程度上的共识,再去动手构造,比较好,这个框架coding的工作量,一个人1小时够了吧,关键还是设计思想。
我正在写文档,会很快将文档放上来。另:早知你一个人一个小时就可以搞定我就不用这么辛苦了。
5,框架是基于对项目的抽象,所以项目中出现的问题,应该在框架中体现出来,所以适合做过项目的人去搞,比较容易去按解决实际问题的思路去思考。
些框架用于以数据库为中心的C/S结构的程序开发,主要用于解决一些最一般的问题,例如:数据存取与共享、事件控制等等。其实这个问题我之前已经贴过了,请你看一下些贴<SmallSruct 3简介>
6,这个框架是准备以什么结构去构建?cs还是三层?
同上一问题。
7,这个框架是否可以对项目中出现的问题,得到很好的解决,而这些问题是什么?
比如,如果数据源是动态的,就是选择什么数据源要靠用户选择才知道,那么数据模块部分如何来适应这种需求?
不明白你指什么,如可能,请详细说明。
8,用三方构件吗?那要是以次框架去做项目,版权问题如何解决?其实,三方构件用的比较多的是界面的表现上,而内部处理倒是不用。如何权衡?
这个问题,我想是不是这样,你现在的框架已经分离了界面和处理部分,内部处理基本能够达到通用,而外部处理,界面和报表部分,不如分出来,用标准构件,然后把这一部分的制作步骤文档化,别人可以很方便的来特异化自己的表现部分。
如你所说,Model和View是分离的。三方控件都用在View上,比如Button、Backgroud、Report、Grid。除DevExpress Grid Suite处其余控件均可有可无。
9,溶入AD(application dictionary)概念如何?至少查询部分实现起来会比较方便
不明白AD是什么,能否详细说明?像查询、报表、数据校验、动态字段的配置这一类功能不属于框架,但在框架里有一定支持,若要做到这些功能亦很容易,我会在例子中演示。框架本身只提供了最基本的功能和诸多策略,所以有很好的扩展性,这些功能都可以在框架上实现。
10,项目整合如何考虑?用插件技术?比如开发了一个项目,后来追加功能,原本是个小项目,结果象雪球一样滚的很大,当然delphi用一个应用程序可以完事,可是,如何出现这种情况怎么办,我基于这个框架开发了a,b,c三个系统,分别给不同的单位使用,后来一个单位都想使用,当然要集成到一起,该框架,是否考虑这个问题?
其实这个问题我之前已经贴过了,请你看一下些贴<SmallSruct 3简介>。你说的这个功能是有的。
----------------------------------------------
- |
作者: |
|
2004/5/7 12:59:38 |
1楼: |
谢谢解答,继续关注
----------------------------------------------
-
|
作者: |
|
2004/5/7 14:11:29 |
2楼: |
1,最新的版本调试不能通过,有几个以pp开头的单元找不到 这是ReportBuilder 7。 ----选用三方构件,真的让人很矛盾:)
3,框架正在分析,不过是基于以前版本的
之前的SmallStruct2与现在的版本有很多不同 ----是SmallStruct3,不过是前两个a版,好像没有用RB。
4,建议斑竹还是写些东西,比较清晰的传达你的设计思想,这是讨论的基础,不要到头来,重新构造你的类体系。而讨论也应该基于文字,而不是代码。等大家达到某种程度上的共识,再去动手构造,比较好,这个框架coding的工作量,一个人1小时够了吧,关键还是设计思想。
我正在写文档,会很快将文档放上来。另:早知你一个人一个小时就可以搞定我就不用这么辛苦了。 ----能提供文档最好,我的意思是,相比之下,编码容易的多:)其实,我关注这个框架,主要也是基于要理解你的设计思想。
7,这个框架是否可以对项目中出现的问题,得到很好的解决,而这些问题是什么?
比如,如果数据源是动态的,就是选择什么数据源要靠用户选择才知道,那么数据模块部分如何来适应这种需求?
不明白你指什么,如可能,请详细说明。 ----是这样,比如业务数据,可以一直存在一个库中,但是用过几年之后,谁着数据的增加,性能可能下降,所以,有时候可以按年度将数据进行分割,这样就会出现两个或者多个同样的数据库,而用户在进入的时候是要选择的。类似财务软件的帐套概念。 这是其中一个问题,可能还有其他的,暂不细说。
8,用三方构件吗?那要是以次框架去做项目,版权问题如何解决?其实,三方构件用的比较多的是界面的表现上,而内部处理倒是不用。如何权衡?
这个问题,我想是不是这样,你现在的框架已经分离了界面和处理部分,内部处理基本能够达到通用,而外部处理,界面和报表部分,不如分出来,用标准构件,然后把这一部分的制作步骤文档化,别人可以很方便的来特异化自己的表现部分。
如你所说,Model和View是分离的。三方控件都用在View上,比如Button、Backgroud、Report、Grid。除DevExpress Grid Suite处其余控件均可有可无。 ----三方构件,是个问题,不如去掉,就用d本身带的,让用的人自己去做这部分。
我想我还不太熟悉你的框架,正在看,也会及时反馈一些东西。 新的问题: 1,能否将逻辑上一致的单元合并?这样使用或者阅读都方便,粒度怎么划分好?感觉现在的单元分的太细,小的,逻辑上属于一类的可以考虑放到一个单元,大的,独立的放到一个单元。 2,我尽快的装上ReportBuilder 7吧,不然,最新的我看不到。 3,可能的话,我做个例子,用你的框架,相对复杂一些的,不过可能会有问题,到时候就要问你了。 3,ad是应用程序字典,或者字典驱动,也就是根据数据字典来进行程序控制。 比如说,有一个商品目录,根据数据字典可以用你的框架实现单表编辑,而不用写一行代码,一个程序类似商品目录的大概有3,5个或者更多,如果用数据字典的话,基本就是定义就可以实现,修改,扩充都比较方面,类似的还有一些简单的查询。 字典要考虑的是如何定义结构,如何存储(流,文件,库中),你的框架要是能方便的支持它,就更省事了,呵呵,程序员总是不愿意做重复劳动。 比如把字典传递到你的数据模块中,相应的(主界面出现相应的菜单,图标,点击调用你的解释模块)问题就解决了,不用编程 这个可能和你的设计初衷不一致,但是框架就是用来省事的,这是共同点。
----------------------------------------------
-
|
|