大家好！<?xml:namespace prefix = o ns = "urn:schemas-microsoft-com:office:office" />
我平時用DELPHI編ERP程序,出於安全和效率的原因,最近幾個月在學J2EE，也許是DELPHI用慣了，總覺得JAVA好是好，就是開發過程太繁瑣了，不符合“開發以人爲本的"理念。下面是根據我的需求草構的一個理想中的ERP開發框架，大家能否就這個框架提提意見，看看是否可行？
因本人編程水平有限,只能說個大概，但相信應該有很多高手能領會我說的意思吧:
1.此框架由三要素組成：組件、SQL、用於服務器端的一種面向對象的語言(可以爲JAVA、C#、C++、OBJPascal或一種中間語言)。
2.它的核心是組件，類似於DELPHI中的Tform,Tedit,Tlabel,Timage,Tdbgrid組件等，一個組件由運行於客戶端的表示層和服務器上的主體層構成，表示層可由不同的語言寫成，分別運行於WEB，WINDOWS，LINUX,手機等平臺,表示層與主體層之間通過加密式HTTP協議耦合,是不可分割的,組件具有自校驗功能，客戶端不可能篡改組件的表示層。例如同樣一個Tdbgrid組件，在windows窗口環境下表現爲一個帶彙總、排序、導出、打印功能的表格控件，而在Web環境下就變成了一個具有類似功能但表現爲自動分頁顯示的WEB表單，而在手機環境中僅表現爲帶滾動條的文本列表。
3.程序主體在服務器端運行，服務器容器實現對象池、連接池、線程管理、SQL優化(若有可能自動編爲對應本地數據庫的存儲過程), 客戶端運行的只是組件的表示層，用於客戶的信息輸入及輸出，客戶端相當於服務器端的一個映象，例如，服務器端生成一個窗口對象，客戶端就會彈出一個窗口，服務器端的窗口對象上再動態生成一個按鈕對象，客戶端的窗口上也就會出現一個按鈕。
4.程序員只針對組件編程，放棄對錶示層細節的維護,可以實現讓不懂編程的美工和程序員真正分開。例如:程序中有一個主窗口,一百個已確定的彈出窗口，以及若干個不確定窗口(窗口類型及其子組件在運行期動態生成，不能在IDE中用拖放的形式確定),這種情況下,可由美工針對每個確定的窗體,由工具軟件來進行美化,產生若干個類似於CSS的格式文件,如:
Form1
windows窗口環境下:形狀=圓角方形(寬=600;高=400);窗口底色=灰;標題欄=藍色
Linux窗口環境下:形狀=正方形(寬=默認;高=默認);窗口底色=灰;標題欄=紅色
瀏覽器中:形狀=圓形;標題欄=無;花邊=花邊1.jpg;彈出聲效=嚇一跳.wav;效果=淡進淡出
手機中:形狀=帶上下滾動條的容器
Menu1
windows窗口環境下:底色=深灰;圖標們=ICO1.ico,ico2.ico...;
Linux窗口環境下:取默認值
瀏覽器中:風格=自定義菜單1.風格
手機中:形狀=滾動的菜單項
Button1
windows窗口環境下:形狀=標準按鈕(top=10;left=10;寬=100;高=50);底色=灰;圖標=按鈕圖標1.bmp
Linux窗口環境下:形狀=橢圓風格(top=默認;left=默認;寬=默認;高=默認);底色=灰;圖標=無;
瀏覽器中:形狀=動畫按鈕風格1,位置=默認
手機中:形狀=文字菜單
.....下略.....
至於動態生成的窗口、菜單等組件，解決方案有兩種：1是由程序員來維護 2是取默認CSS風格
5.直接用SQL操作數據庫，不做O-R映射(對於小企業編程人員來說,學會SQL已經很不錯了,再學什麼O-R就有點強人所難了，他們要的是學得快而又功能強的速成方法),
爲了提高寫SQL語句速度,我推存一種方法:先在EXCEL等電子表格中寫好數據庫的結構，有以下好處：
1).EXCEL表便於今後寫文檔，(實際上數據結構表你總是要寫的);
2).可用工具(我自己已編好)直接根據EXCEL表創建空數據庫並加上各種鍵和約束.而且可看性可維護性比直接寫create table Child(Id int not null auto_increment primary key,Name varchar(100))之類的語句好多了。
3).編程時將EXCEL片段貼到程序中就寫好了insert、update語句，加快編程速度(見下面示例),
4).省去了寫字段的中文註釋
5).可利用EXCEL生成SQL查詢語句，不用在鍵盤輸一個字母，就能將數據庫的內容顯示在DBGRID中並加上中文字段名。（具本方法因篇幅有限這裏略過）
最好將來在IDE中可以直接支持嵌入"EXCEL表"格式,爲什麼這麼說呢？你將下面從pu_insert開始到cd_tmp.first之間的行粘到EXCEL中就明白了：它在EXCEL中對齊了,因爲它原本就是直接從EXCEL中粘過來的。
以下是用DELPHI語言編的一個發貨過程示例：
string1:=cd_order.XMLData; //保存服務器端訂單主表的數據
public_begintrans_repeatable; //調用SQL開始事務,控制事務等級爲repeatable
try
view_reflash; //刷新訂單主表服務器端視圖
if (cd_order.XMLData<>string1) then raise ematherror.create('操作失敗:當前訂單內容已被其它人更改，請檢查訂單');
if pu_getonestring('select fhdcode from fhd where fid='+factid+' and fhdcode='#39+cxbuttonedit1.text+#39)
<>'' then raise EMathError.Create('錯誤:同號的發貨單已存在!');
pu_insert('fhd',[ //寫發貨單到數據庫中
' Fid integer 工廠代號 '+ factid
' FHDCode Varchar 20 單據編號 '+ cxbuttonedit1.text
' OrderNo Varchar 20 必填 定單編號 '+ cxtextedit3.text
' FHDDate datetime 必填 發貨日期 '+ pu_today
' Remark Varchar 200 備註 '+ cxtextedit6.text
' car Varchar 10 車隊代號 '+ cxtextedit1.text
' receiverman Varchar 10 收貨人 '+ cxtextedit5.text
' DeliverTo Varchar 80 交貨地點 '+ cxtextedit2.text
]);
cd_tmp.First;
while not(cd_tmp.Eof) do //待發貨的機型存在cd_tmp中
begin
pu_exec('update stkcrd set qty=qty-'+cd_tmp.fieldbyname('發貨數量').asstring
+' where fid='+_factid+' and modle='#39+cd_tmp.fieldbyname('成品型號').asstring+#39); //更改當前庫存
cd_tmp.next;
end;
(...下略...)
pu_commit;
view_reflash_both; //同時刷新服務器端和客戶端的視圖
tell('發貨成功,發貨單號爲:"'+cxbuttonedit1.Text+'"');
if iftell('是否現在打印發貨單?') then sale_printfhd(cxbuttonedit1.Text);
cxbuttonedit1.clear;
except
on E:EMathError do begin pu_rollback;tell(E.Message) end
else begin pu_rollback;tell('程序出現未知錯誤,請與系統管理員聯繫') end;
if debug then raise;
end
//說明:pu_insert(...)在實際編譯後是按"insert fhd (fid,FHDCODE...) values(1,'XXXXXX',...)"的標準SQL語句來運行的,也就是說，中間的” VarChar 10 收貨人”相當於註釋，增加了程序的可讀性。
6.不區分MVC層次，簡化開發過程。從上面的代碼中，大家可以看到，以上代碼是典型C/S模式下MVC不分的代碼。但MVC不分也有它好的一面：代碼簡潔。MVC提出的初衷是什麼？初衷之一是怕企業邏輯寫在V層被人篡改, 本架構中因爲V層只是組件的一個組成部分，而主體運行在服務器上，不可能被篡改，所以直接針對V層(組件層)編層不再是缺點反而是它的優點,它省去了C層和V層兩個開發層的人員之間的溝通，MVC初衷之二是表示層與邏輯層混在一起不利於維護，但本架構中因爲一次編寫，到處運行，完全放棄了組件表示層(交給美工了)，天生就不存在程序員要寫HTML，美工要寫JAVA腳本的問題，所以維護起來非常方便。再說對於小企業來說，一般也不存在企業邏輯要重用的問題，如果非要重用的話，將企業邏輯寫在一個公用過程中調用就行了。
7.除非有打印、導出的客戶端需求，它的數據處理都在服務器端。例如一個訂單表有一萬個記錄，客戶端每翻一次屏，服務器端就從數據庫中取20個記錄同時顯示在DBGRID組件的服務器端和客戶端，響應速度很快。有點象Delphi的MIDAS技術，但從技術上來講比MIDAS更容易理解。
8.安全性:完全建立在組件上，每個組件設計必須確保沒有安全漏洞，寧缺勿濫。
9．運行效率：不亞於J2EE或.NET，直接利用J2EE或.NET實現服務器端容器也可,若追求效率穩定要求不高的情況下，服務器端可實現原生碼組件容器。
10．有一個集成式IDE，支持組件拖放，支持IDE內編譯調試發佈，無需ANT支持。
11.安裝方便，一次安裝就確保成功，不需要手工設什麼環境變量。
12.該框架與其它相似技術的區別：
該框架與Tapestry區別:Tapestry只能開發WEB,只能使用java,而此架構可實現一次開發到處運行,支持各種語言。
該框架與.NET框架的區別:.NET必須針對WEB和窗口環境分別開發,且鎖定在windows環境。
與Macromedia的Flex區別在於:Flex側重於XML表示的表示層，將Ｃ層與Ｖ層分開了，且只能用於flash控件。
與微軟的XAML的區別：XAML側重於表示層，將Ｃ層與Ｖ層分開了,且只能用於longhorn平臺。
與Mozilla中的XUL的區別:XUL側重於表示層，將Ｃ層與Ｖ層分開了，且只能用於Mozilla瀏覽器。
與webwork的區別：webwork鎖定在了java平臺的ＷＥＢ開發。
13.該框架缺點：1)程序中不能使用對平臺依賴的API調用(對於ERP程序來說其實影響不大) 2)因爲直接對數據庫和界面操作,修改企業邏輯很方便了，想到什麼，立即隨手就能在代碼裏實現了，以致於我現在畫的流程圖(我到現在也沒找到一個合適的建模方法)跟不上我修改編碼的速度(我現在編的CS結構的ERP程序),整個程序象一堆麪條攪在一起。不過有一點是肯定的，我編程和交流時一直用流程圖，決不用什麼UML圖的，對於一個經常連自已需求都搞不清的小企業來說，沒必要用對象包裝，多此一取,事實上，RMDB中的每個表就是天然的對象了。
我不知道大家對這個框架是怎麼看的，反正它就是我想要的理想中的適用於中小企業的ERP開發工具:學習週期短(無需學JSP,SERVLET,HTML,.NET,FLASH，ANT,struts,Hibernate等等,只要學會十幾個組件的用法就可)，開發速度快，安全性好，支持高併發訪問量，一次編寫到處運行(只要客戶端能實現組件的表示層)。
題外話：我認爲快速原型開發方法非常實用，它可以不要求程序員對企業專業知識學得很深,理想中的開發進度應該是這樣的：開發的時間≈獲取需求的時間。我不明白爲什麼兩個小時就能講明白的需求爲什麼會花一個月的時間去開發？如果客戶在兩個小時之內提出一個不明確的需求，哪我們就在兩個小時之後給他一個粗糙的可運行的原型就行了。反正程序是改出來的，又不是蓋房子蓋好了就不能改了。客戶覺得不好，他會告訴你怎麼改的。如果客戶在一個月內給你一個非常詳細的需求，估計你至少也得花一個月才能編出程序來。程序是客戶和程序員協作出來的。如果協作了幾個月後，客戶才明白他真正的需求是什麼，而對程序員來說卻是很難實現的(客戶忽然有一天要求程序員在8秒內跑完100米)，這種情況就很麻煩了,如果毀約有錢拿還好，沒有錢拿的話，這幾個月就算白乾了,要避免這種情況，只有兩種辦法：一種辦法是按合作期收錢（目前似乎沒有哪個軟件公司牛到這個地步）,另一種辦法就是在合作之前就培訓客戶，把我的最後這段念給他聽,讓他知道”程序是合作出來的”這個基本道理,告訴他合作期間提出非份需求對開發成本及進度將會是的致命，保證即使毀約也要對程序員作某種補償。另一個問題是：如果客戶確實沒有錯，他當時確實說是要8秒跑完100米的，只是程序員理解成了80秒跑完100米，怎麼辦?沒什麼好辦法,溝通得再好,也不可能避免出錯的，但是減小損失的途徑是，如果開發速度非常快的話，本來要一個月乾的活，三天就幹完了，也就相當於少損失了27天的錢，這裏就體現出開發速度的重要性來，總之我理解的框架的最終目標就是“加快開發速度”。
附框架示意圖：
<img src="http://go.nvt.cn/zhangrex/kj.jpg">
