Delphi 三层C/S 的 MVC 模式 请有兴趣的大虾们进来灌水(100分)

D

dgl007

Unregistered / Unconfirmed

GUEST, unregistred user!

• 2004-05-18

• #1

小弟近日在做一个面向全省服务的社保系统分析，在系统架构方面考虑使用C/S＋B/S的异构体系。B/S做一些简单的数据录入和简单的查询，C/S处理复杂的业务。核心是C/S方面，我打算用Delphi 实现。UI没有业务逻辑，仅作一些简单的判断；业务逻辑中间层（Control）封装在 大量的DCom组件中。M唯有直接就是数据库了。具体的实现就是 客户端用ClientDataSet获取数据但是并不设置ClientDataSet的Provider属性，也就是说，ClientDataSet 获取数据后就完全与应用程序服务器断开连接了。数据更新时把Clientdataset.data 以OleVariant的形式传回中间层服务器更新数据库。各位大虾对这种做法有何看法请多多赐教：）

 

Z

zhaogh_2171

Unregistered / Unconfirmed

GUEST, unregistred user!

• 2004-05-18

• #2

我也对此感兴趣。

 

踏

踏浪99

Unregistered / Unconfirmed

GUEST, unregistred user!

• 2004-05-18

• #3

呵呵，不错的想法，不过我还没见过有人这样做

 

F

futurelife

Unregistered / Unconfirmed

GUEST, unregistred user!

• 2004-05-21

• #4

可以实现,类似web services，我正在做这方面的系统

 

M

mstar

Unregistered / Unconfirmed

GUEST, unregistred user!

• 2004-05-21

• #5

不怎么地 性能不佳

 

H

hygsxy

Unregistered / Unconfirmed

GUEST, unregistred user!

• 2004-05-22

• #6

浅谈一下想法.
作为面向全省服务的社保系统,我认为关键的还是要考虑它的异构环境的交互和延展.你的这个系统的实现可以采用的方法很多,你不能为了完成一个工作而工作,你必须在做你的系统之前就要考虑到诸如其他语言开发的多层系统是否能够访问容易(如果有这种可能的话),日后的升级和维护是否容易,技术上实现的可行性等等.也只有权衡利弊之后的决定才是你整正要开始实施的..
先说业务逻辑中间层（Control）封装在大量的DCom组件中,DCOM的缺点如下:延展性差,技术复杂,交互困难,分发困难,与防火墙集成困难等等.我建议你还是考虑下soap/weservice+后端数据库.

 

B

bluesaga

Unregistered / Unconfirmed

GUEST, unregistred user!

• 2004-05-24

• #7

呵呵～～有想法。

 

D

dgl007

Unregistered / Unconfirmed

GUEST, unregistred user!

• 2004-05-25

• #8

非常感谢大虾们的参与！：）
futurelife兄，可以谈谈您的具体实现吗？比如说从服务端提取一笔数据到客户端做相应的修改作相应的业务逻辑判断的这一过程是具体怎么实现的呢？

 

L

lzm

Unregistered / Unconfirmed

GUEST, unregistred user!

• 2004-05-25

• #9

我用BCB做三層的工廠系統，有海外和大陸客戶同時上線實施成功的經歷。1.建議你放棄WEB,不是他不好，而是你後繼的維護，功能的控制方面，你會被它累死，而不是將主要的精力放到你的業務邏輯。
2.我的用的Midas+Scket+ADO+Sql 對DCOM,對於DCOM誠如hygsxy所說，
維護不方便。
3.取得數據，可動態設定Provider。取到後用Clientdataset的SaveToFile存到本地，需要提交時再連上去.這種做法可行，李維的書上也有講，也有實做過。

 

L

lzm

Unregistered / Unconfirmed

GUEST, unregistred user!

• 2004-05-25

• #10

另外說明一點，也許你用不上
你得考慮用戶的OS問題， 我們的客戶SQL是繁體，可END USERE有各種版本時， 資料錄入進去可能是不同的內碼，雖然說可以控制做轉換，但一直還沒找到省力方便的辦法。

 

D

dgl007

Unregistered / Unconfirmed

GUEST, unregistred user!

• 2004-05-26

• #11

我以前曾负责ERP的开发，采购、库存、销售等共19个模块，服务端只有一个用DCOM
连接数据，给每个ClientDataSet一个对应的Provider，服务端只是起到数据连接的
作用，业务逻辑都做在客户端。对于小组开发和维护都非常不方便，而且两个开发部
在两个不同的城市，苦！
我比较倾向于组件开发模式，无论是开发协调性还是可维护性都会比较有优势。
浅谈我的设想：把一个个的功能粒度化，客户端：一个功能用一个bpl实现，根据
不同的菜单调用不同的bpl包，客户端实现组件化；服务端：我希望把业务逻辑封装
在服务端，并且服务端也是由不同的组件包实现不同的功能，跟Java中的
Session Bean差不多。
lzm兄的做法中，不知是否能在服务端也封装了相应的业务逻辑？还是跟我以前的ERP
系统的做法相似？希望lzm兄能继续参与讨论，当然希望有更多的大虾能给出您宝贵
的建议和继续关注 ：）

 

L

lzm

Unregistered / Unconfirmed

GUEST, unregistred user!

• 2004-05-27

• #12

客戶端照你的做法.問題不大,而且可行.在對數據權限控制要求比較高時更
合適.對於服務端,業務邏輯包裝在裡面,我們以前做過,開發時的確方便.但
是有一個問題出來了,系統的可維護性,一些公用接口,參數的統一等等,我們
公司後來被搞得頭大.然後又回到業務部分寫在前端裡面.
側重點不一樣,採用的方法會差很遠!看你的系統隻在內地使用.寫在服務端
也是可行的好辦法.但服務端但由N個組件包來實現,從商業角度看,開發的成
本是不是高了點?

 

D

dgl007

Unregistered / Unconfirmed

GUEST, unregistred user!

• 2004-05-27

• #13

To lzm:
服务端封装业务逻辑，也只是我的一个理想。具体怎么实现，如何定义统一的接口等方面我没有细想。过两天我想个方案再请您指点一下。且先说一下数据更新速度的问题，请问你是用ClientDataset的ApplyUpdate方法更新数据的吗？当数据表记录上百万以上，并且是主从表结构时，你们是不是会发现数据更新速度很慢呢？对于这种大表，我打算自己用SQL语句更新数据库而不用ClientDataset的ApplyUpdate。我发现ClientDataset提了一大笔数据到客户端直接用ApplyUpdate更新数据库速度非常慢。你们遇到这样的问题吗？你们会借鉴B/S一样分页提取数据到客户端吗？

 

L

lzm

Unregistered / Unconfirmed

GUEST, unregistred user!

• 2004-05-27

• #14

關於數據更新,別說幾百萬啦,幾萬都不行的.就算再寬的網絡都不太好.
1.你的主從表,千萬千萬不能用自帶的MasterDataseroc的方法去關聯次檔
如果一個主表有幾個次檔時,用這種方法更是一場惡夢.雖然在c/s裡不覺得.
一般我的做法,主從開檔時先隻開主檔, 主檔的PacketRecord還是要設的. 利
用PAGECONTROL來切換時,寫在ClientDataSet1AfterScroll, 來開次檔.當然
你可直接用param,或者直接傳SQL命令行過去. 建議你還是傳SQL過去,靈活
得多.更新還是用ApplyUpdate, 一般主檔的AfterPost裡,我會下pplyUpdate.當然也會先用CheckBrowseMode去檢查一下啦. 一般來說一次異動過去也就
幾百或幾千筆.
2.我的經驗是客戶一般都是怕在開檔時慢,或者怕報表時慢.處理好這二個,你
就成功一半啦!
3.另外問一下,你們這套系統的價位在哪個區間? 我是在外資公司,隻是想了
解一下.不存在商業利害關系,不知願告知否?

 

D

dgl007

Unregistered / Unconfirmed

GUEST, unregistred user!

• 2004-05-27

• #15

To lzm:
呵呵，价位还没怎么定呢，老板还在谈，不过我粗略估计了一下，这套软件的开发成本大概能在40万以内吧。所以价钱的问题还是老板说了算的。

 

D

dgl007

Unregistered / Unconfirmed

GUEST, unregistred user!

• 2004-05-27

• #16

To lzm：
你们现在的服务端，是做了一些公用的DatasetProvider，当客户端需要更新数据时才连接更新数据是吗？由于我们以前是每个ClientDataset连接一个DatasetProvider所以开发过程中总是需要不断的合并服务端。如果是按照你们现在的做法应该不会出现这种情况吧？其实，我想把业务逻辑封装在服务端主要是考虑到用户分布较广尽量做到版本更新时只更新服务端就行了，而不想每个终端都要去下载升级包。
如果把业务放在服务端我还是打算把ClientDataset的Data传到服务端，用通用方法根据data的是否有编辑过、新增、删除的数据生成SQL语句去更新数据库。只是这里会出现一个问题，就是Delphi用SQL更新数据库是如何启动事务的呢？

 

L

lzm

Unregistered / Unconfirmed

GUEST, unregistred user!

• 2004-05-27

• #17

DatasetProvider是公用的.
如果你把DATA傳到AP端去更新的話,的確要考慮事務. 不過這個我是沒正式
實作過.好象書上有講,查查看.我用BCB,還沒研究過其實現方法.

 

P

paul_geng

Unregistered / Unconfirmed

GUEST, unregistred user!

• 2004-05-28

• #18

1.服务端使用公用或者独立DatasetProvider其实都不是多大的问题,问题在于你在设计时需要明确,我从数据库取得数据后就不再与数据库交互,除非是我提交修改的数据(分页取数据只是一个性能的折中).这才是三层的精髓,存在的优势.
2.中间件所引出的方法应该越少越好,只需要提供数据交换接口就好了,既是delphi的DatasetProvider,至于对于提交的数据的处理就是服务端的业务了,也就是以上几位仁兄提的业务作在服务端.
3.既然做三层,就不要去想在你做每一条数据的时候就去到后台验证你的数据正确性,记住你做的是分布式的事情,怎么可能动不动满世界找你的数据,这是客户端数据库clientdataset,
不是查询query !!!!!

 

J

jmlwz

Unregistered / Unconfirmed

GUEST, unregistred user!

• 2004-05-28

• #19

如果要面向全省的话，可能要考虑到数据发送的问题吧，数据需保密吗？DDN很贵的，ADSL安全吗？

 

J

jhwh

Unregistered / Unconfirmed

GUEST, unregistred user!

• 2004-05-28

• #20

按照楼上的这些做法,根本不可能和UI分离.如果要分离,你必须得自己包装很多东西,比想象的难得多.不是打击各位,从各位解决问题的思路来看,是不能完成这个工作的.顺便说一句,如果想自己能够实现逻辑界面分离,只是有数据库开发经验是完全不够的,接触的领域越多,对掌握OO越有利.
现在很流行OR Map,我敢打赌,即使使用了这些工具,各位的代码还是不能和UI分开.因为这些东西的性质是一样的,如果真正掌握了OO,那么你会发现开发中,你和这些控件打交道的时间很少,甚至于最多只占你的代码的10%左右.之所以出现这种情况,原因在于,类是用来表达概念,我们的企业逻辑代码完全是和概念打交道,根本和 TDataSet 无关.而且在需要数据的时候,这些数据已经由持久层管理了,那么各种数据的操作完全通过标准方式进行,至于是用哪个 TDataSet 的派生,完全不需要关心.三层不过是传输数据而已,和企业逻辑完全无关,我们只需要考虑效率就行了.