《Delphi面向对象编程思想》 (0分)

B

barton

Unregistered / Unconfirmed

GUEST, unregistred user!

• 2003-07-09

• #81

>>我不清楚其他工程中客户端的GUI控制花费了多少开销，但是在我最近从事的工作中，
>>GUI的控制代码至少花费了开发时间的70%以上，而且贡献了大量的BUG，这些在我看来主
>>要是不使用数据感知控件的结果（受限于BDE连接数，所以一直没有使用），这显然是不>>正常的。

不能理解。在我的项目中GUI一般不会超过1/3工程量。体系、类封装、数据占1/3工作量，
特别的技术及业务占1/3工作量。而且不使用数据感知控件会导致Bug?不可思议。

我心目中的o/r mapping不仅仅是一种关联。我希望在开发流程中，这两者高度统一在一
个第三者中，控制这个第三者以达到控制业务与数据。这个第三者就是全部的业务规则。
数据库的访问、对象映射全面依赖这个第三者(不是运行期对象而是设计期对象)。界面
只是控制可视控件间的协作关系，然后调用内部业务对象而已，怎么会花费70%工作量？

 

B

barton

Unregistered / Unconfirmed

GUEST, unregistred user!

• 2003-07-09

• #82

~~~~~~~~~~我的印象中什么时候也没有因为界面给我的项目带来BUG~~~~~~~~~~~~~
困惑中......

 

T

Traveller

Unregistered / Unconfirmed

GUEST, unregistred user!

• 2003-07-09

• #83

我也不想这样，可是事实就是如此，现在正在为此而苦恼呢。
因为这是一个6年前的项目，我们新加入进来就是为了维护它，他的公用类体系设计的比较糟糕，但是因为要改动的工作量巨大，所以一直没人敢动 :-(
BUG也不是那种底层的BUG，主要还是界面控制方面，比如某个按钮没有置灰，某个编辑框的TabOrder不对，某个编辑框的文本长度没有限制，都是遗留下来的很简单的小问题，但是却占据了大部分的工作量，非常不爽。而由于必须使用公用类体系，所以新增的系统中这类问题又是层出不穷。
代码里面到处都是
edtName.text := FieldByName('Name').AsString;
之类的代码，数据校验和数据修改未保存检查更是繁琐。但实际上这些工作通过数据感知控件是很容易消除的。我曾经在一个相对独立的工程中试验过基于MIDAS的方式，数据录入部分的代码还不到用非数据敏感控件的1/3。
现在我也不知道该怎么办，我一个人是不可能推动这个产品进行一次重新设计的。

 

T

Traveller

Unregistered / Unconfirmed

GUEST, unregistred user!

• 2003-07-09

• #84

我想这个产品的问题可能已经不仅仅是技术方面了，工程管理方面更为严重一些。

 

速

速查手册

Unregistered / Unconfirmed

GUEST, unregistred user!

• 2003-07-09

• #85

个人观点：
真要面向对象，强烈建议学习C++，当然在项目中你不一定用它。

看一下《C++ 程序设计语言（特别版）》的23、24、25章和《设计模式》（也有for pascal的），与真正的老师对话吧。

如果想成为真正的程序员，C/C++还是不要绕开的好...

哎！“坦途”实为“邪路”，“天堑”才是“通途”，某些delphi程序员，睁开眼吧。

 

B

barton

Unregistered / Unconfirmed

GUEST, unregistred user!

• 2003-07-09

• #86

也只能是个人观点而已。我还看到有位专家讲，面向对象应该向JAVA看齐呢。

 

B

barton

Unregistered / Unconfirmed

GUEST, unregistred user!

• 2003-07-09

• #87

用什么语言纯粹是个人的爱好，干嘛非要强奸别人的思想？可笑至极。

 

K

ka52

Unregistered / Unconfirmed

GUEST, unregistred user!

• 2003-07-09

• #88

速查手册 :
<< 哎！“坦途”实为“邪路”，“天堑”才是“通途”，某些delphi程序员，睁开眼吧。>>
也不看你回答了些什么有价值的问题,在这说别人如何如何.
你的意思我明白,但请你不要以这样的口气说这话.

每个初学者刚学delphi的时候基本上都是这样的,看了那么多控件,
左看右看,越看越搞不懂,越不懂越看.这是很正常的.

但Object Pascal又有几个人说自己会的,站出来.
又有几个人说自己看懂VCL的.

我是初学者,到现在还不会Object Pascal(不是Pascal!),对于类能不用就尽力不用.
现在正在努力改正.
刚刚写了个控件,花了一下午,才深知自己对Delphi的陌生.

语言不是问题,问题是自己!!!

to 刘艺:你的书我没看过.但你的书不在我朋友推荐的书里面.
希望你努力,把书写成一部经典.
一本好书,会让一程序员受用一辈子的.
一个流行书,可以让一个程序员用2个月.
一本垃圾书,买了就扔.
希望你的书下次出现在我朋友的推荐书单中.

 

特

特尔斐

Unregistered / Unconfirmed

GUEST, unregistred user!

• 2003-07-09

• #89

我曾买了刘老师的《DELPHI5企业级解决方案》，虽然觉得不怎么样（也许是我没看懂），但我还是觉得他很有度量。
不象DFW上面的某些高手，听不得别人的不同意见，动不动就开骂。
所以，我觉得刘老师的书一定会越写越好的。[]

 

Y

yyanghhong

Unregistered / Unconfirmed

GUEST, unregistred user!

• 2003-07-10

• #90

delphi与面向对象
Java与模式,
为什么中国的作者喜欢把语言和开发方法放到一起写呢?

 

B

barton

Unregistered / Unconfirmed

GUEST, unregistred user!

• 2003-07-10

• #91

请刘艺先生看看我对Data Aware的评述：
http://www.delphibbs.com/delphibbs/DispQ.asp?LID=2010662
是否能够给出用数据感知控件的替代方案。我认为这是一个很有意义的讨论。

 

Y

yyanghhong

Unregistered / Unconfirmed

GUEST, unregistred user!

• 2003-07-10

• #92

对数据感知, borland做了很多工作, 他占用内存不大, 速度也很快, 开发效率高, 但用它不易于设计程序架构, 而且对于复杂点的数据库操作不是很方便, 比如操作partition table, 或批量修改.你只能用sql或stored procedure直接操作, 这使数据库操作变成了两块
OR MAPPING适合于对速度要求不是非常严格的系统, 并且我们也可用cache或filter技术去改善它. 用户不需要一下子就得到所有数据,
用OR MAPPING可帮助设计好的架构, 而且和后台database打交道直接一点.你可把很复杂的操作通过更改属性加在你的data gateway类中.

http://www.delphibbs.com/keylife/iblog_show.asp?xid=300

 

B

barton

Unregistered / Unconfirmed

GUEST, unregistred user!

• 2003-07-10

• #93

我的看法可能比较极端一些：对于中/大型系统特别是维护量大的系统，数据感知完全设有
办法解决问题。离开了数据感知，整个数据集体系就变成臃肿不堪了，就象提着一辆破烂
的自行车去爬山...
为了实现一记录一对象，Delphi应该作重大改革，一是让开发者尽可能地轻化设计过程中
数据库系统的机能，完全摆脱对数据库本身功能的依赖，减轻数据库系统的负荷而将更多
的工作交给对象体系去处理；二是重新设计数据集体系，提供一些更加高速、简便的数据
库访问框架，以便高速地实现对象的生成和呈现；三是修改数据感知的概念，使GUI对数据
集的依赖变成对一些通用接口的依赖，为开发者提供更大的设计空间。

 

Y

yyanghhong

Unregistered / Unconfirmed

GUEST, unregistred user!

• 2003-07-10

• #94

borland近期是不会对delphi进行大改动的, 他把主力都投放在c#builder上了.

 

速

速查手册

Unregistered / Unconfirmed

GUEST, unregistred user!

• 2003-07-10

• #95

[][][]
我不是“语言至上论”者，更不想挑起口水战（这些东西太多了），但是请大家也不要忽视[red]C++的资源[/red]，那些真正使你“内力”增长的东西，看看那些书的出版日期，你还期待什么？

 

速

速查手册

Unregistered / Unconfirmed

GUEST, unregistred user!

• 2003-07-10

• #96

to ka52:
自己看不懂vcl不要紧，学就是了：用google搜索 “天方夜谭VCL”。

 

T

Traveller

Unregistered / Unconfirmed

GUEST, unregistred user!

• 2003-07-10

• #97

to borton:
看来我确实没有经历过那么大的系统，经你的分析确实数据感知控件在中大型项目（不仅是指规模，更重要的是复杂度）中存在不少缺陷。这方面还得继续向您请教。
而我对数据感知的看法是这样的，不知道能否应用于中大型系统。我认为ClientDataset数据集是作为一种类似Java值对象的方式来工作的，业务逻辑部分可以封装为面向对象的，然后将业务运算结果存入ClientDataset并且传给表现层，表现层对ClientDataset修改之后将提交传回业务逻辑层，业务逻辑层可以根据情况决定如何将他们存回数据库。
这样，复杂的业务逻辑在业务逻辑层按照面向对象的方式处理，而客户端的控件则可以与ClientDataset配合处理各种操作，尤其是对于信息系统这种界面比较多而且比较复杂的应用，我觉得这种方案是比较好的。如果业务逻辑简单，那么仅仅进行简单的对象映射也许就够了。

 

B

barton

Unregistered / Unconfirmed

GUEST, unregistred user!

• 2003-07-10

• #98

其实你表达的是一个数据管道问题。我承认ClientDataset可以充当数据管道这个角色，其
实有很多比ClientDataset更小代价的数据管道，这些需要根据不同的业务类别来处理。很
明显，有约定的数据管道要比无约定的数据管道花费更小的代价。ClientDataset的包有些
大而且安全性差。用一个结构并来回传递试试是不是比Client更好？例如定义一个结构带
以下成员：
PieceSize Word片段大小
Operation Word操作类别(Get/Put/Add/Delete)
NodeID Integer工作节点ID
ObjTypeID Integer对象类别ID
ObjID Integer对象ID
ObjData xxxx
无论是UI还是对象层都可以通过这些约定来完成业务中的功能。数据管道不一定通过面向
对象的方式来实现，实现时可以充分利用操作系统的性能。无端引入TDataset-TFields-
TField是不是有点多余？

 

T

Traveller

Unregistered / Unconfirmed

GUEST, unregistred user!

• 2003-07-10

• #99

我觉得结构并没有很大优势，尤其是如果用结构那么客户端的代码就又得写很多与界面交换数据的代码，并且诸如字段长度等信息在简单的结构中无法传到客户端，而ClientDataset可以连同元数据一起传递。
另一方面，传递结构方式下数据感知无法使用，那么就得写代码来控制各个控件的更新/格式/有效性/取值范围等等，而在对数据感知稍加扩充之后，这些实际上都可以自动进行。还有一点那就是更新的问题，比如你用结构在两层之间传递，那么你就得将整个结构都传回来，而MIDAS做了处理可以仅仅传回修改的部分。
至于安全性，其实不是应该由MIDAS自己来保证的，MIDAS在这里只是作为一种数据打包协议，打包之后你可以用各种方案对这个包进行加密和解密，或者偷懒一点，借用COM+或者Https连接的加密来保证其安全性，这都没问题。

 

T

Traveller

Unregistered / Unconfirmed

GUEST, unregistred user!

• 2003-07-10

• #100

而且，我认为ClientDataset并非仅仅起到一个数据管道的作用，它包含了Java值对象的作用，但同时他还是表示层的中介者，用于简化各个控件之间的关联。