盒子论坛 v2.1

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简介>。你说的这个功能是有的。

----------------------------------------------
-

作者：

canicula (canicula)	★☆☆☆☆	-
	盒子活跃会员

2004/5/7 12:59:38

1楼：

谢谢解答，继续关注
----------------------------------------------
-

作者：

canicula (canicula)	★☆☆☆☆	-
	盒子活跃会员

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个或者更多，如果用数据字典的话，基本就是定义就可以实现，修改，扩充都比较方面，类似的还有一些简单的查询。
   字典要考虑的是如何定义结构，如何存储（流，文件，库中），你的框架要是能方便的支持它，就更省事了，呵呵，程序员总是不愿意做重复劳动。
   比如把字典传递到你的数据模块中，相应的（主界面出现相应的菜单，图标，点击调用你的解释模块）问题就解决了，不用编程
   这个可能和你的设计初衷不一致，但是框架就是用来省事的，这是共同点。

----------------------------------------------
-

信息

登陆以后才能回复