多人開發大型系統,中間層如何組織,一個還是多個? 歡迎大家討論.(50分)

  • 主题发起人 主题发起人 wen
  • 开始时间 开始时间
W

wen

Unregistered / Unconfirmed
GUEST, unregistred user!
十几個人開發一個系統,中間層應怎樣組織,一個中間層還是多個?
歡迎各位大蝦談談自已的開發經驗!
多謝!
 
中间层的组织不看人的多少,而看系统的逻辑关系,拿出来大家看看吧!
 
多謝LeeChange
ERP系統包括系統管理,總帳,應收應付,生產制造等等,有的部份是几個人開發,有的
是一個人開發,各部份之間又有數据關聯.請問這种情況如何划分邏輯關系和分割
中間層呢?
多個人總用一個中間層,應怎樣組織來提高效率?



 
我正好也在作此类项目,我们开始也按业务模块将中间层分开,但后来发现很麻烦!!
所以我的意见是,如果业务之间没有非常非常明显的界限,那么中间层的块约少越
好,这样便于组织数据,另外,最好是开发组横向开发,即每个人只负责一层.客户
端一定要只向服务端发服务代号而不是固定的Sql语句,然后服务端要有一个
服务命令维护表,不同的服务代号对应不同的Sql,这样才可实现真正的三层.
然后中间层如果多人开发,最好按功能模块分工,一些人作存,一些人作统计
一些人作报表等等.
 
多謝Crane的寶貴意見,請再作一下解釋:
服務命令表是以什么形式存在?能舉個例子嗎?
謝謝!

 
你在库里建一个维护表,字段有:服务号,SQL语句,然后加用到的sql语句全添到
此表中,编号,客户端向服务端发服务号和辅助信息比如要替换的内容等.服务端
先解析此服务号,再执行相应的sql语句,这样才可实现客户端代码的相对稳定
 
中间层不能过多,这个意见我同意,不然逻辑关系会把自己也绕进去的.
如用一个中间层,所有参与开发的人得一起设计,至少是人人对中间层都很了解.
至于商用规则的定义,可放在中间层,也可放在数据库服务器上,不放在客户端就行.
Sql语句的变化象孙猴子,如用代号不知长整形够不够(夸张了一点)
直接传SQL语句也没什么,MIDAS提供了多种方法.
 
首先,本来人人对中间层都应该了解,商业逻辑,我个人认为应放在
中间层,否则还叫什么3层结构,另外,SQL应该灵活应用,不应写的
很死,多用参数.直传SQL的话虽然可以,但是假如服务端仅有一个
字段或表名改变就会导致所有的客户端需要升级.
 
本人比較贊同商業邏輯放在中間層.
sql語句用代號傳遞,開發時溝通量大了,運行速度是否變慢(多次解譯),這樣的效率
如何,請Crane談談,多謝!
附加間一個問題:中間層我用ado,再用adoquery關聯多個表資料向前提送數据.
這時向后端提交數据時要自已寫程式拆分數据,工作量很大,后台的數据一致性也較難
保護.請問各位,你們是怎樣處理的?
 
crane:
能不能把你所说的表的内容
列几条出来。
 
no(string) sql(string)
1 select * from table1
2 delete * from table1 where XXXX=:Param
...
...
...
然后将其查到后给Tquery
否则比如c端发了固定的select * from table1
如果今后公司合并,表名重起,客户端就惨啦

 
数据服务层也应该利用一下，这一层只包含必要的数据访问组件，商业逻辑还是
放在中间层比较好。
包含数据服务层组件可使得逻辑层尽量不依赖于具体的数据结构。
 
本人目前准備采用一虛擬接口,把多個中間層結舍在一起,效果還不錯,正在完善階段.
 
多人接受答案了。
 
我觉得可以做多个Remote Data Module,然后在Add to Project.
最好，一个Remote Data Module实现单独的逻辑功能！
 
您必须登录或注册才可回复。

Similar threads

I
IDE Expert
回复
0
查看
800
import
I
Z
發現vclskin的兩個怪現象(50)
回复
1
查看
689
zbdzjx
Z
Z
問大家一個多語言的問題(100)
回复
0
查看
801
zbdzjx
Z
H
誠聘delphi開發人員(10分)
回复
0
查看
727
happygb
H
H
工作需要，誠聘delphi開發人員(20分)
回复
3
查看
430
happygb
H
后退
顶部