【專家問答】韋瑋：Python基礎編程實戰專題【知識庫】Swift資源大集合【公告】博客新皮膚上線啦快來領福利：C幣、機械鍵盤

客戶端是選擇Java Swing還是C# Winform

標簽： swing c#winform service 瀏覽器 java

2012-03-27 11:38 2191人閱讀評論(1) 收藏舉報

分類：

JAVA（7）

本人作品（20）

客戶端是選擇Java Swing還是C# Winform？

在某大型項目中，客戶要求不能用瀏覽器作為客戶端（即不能用B/S模式），而要采用桌面客戶端的方式（服務端用SSH，客戶端通過Web Service訪問服務端應用，並且還要求能在客戶端與服務端網絡中斷的情況下離線進行部分業務操作，例如查詢）。這可給我們項目組提出了一個大問題：客戶端應用開發的技術選型。

公司有些員工強烈建議用Java Swing，認為有一些框架可以利用，例如spring RichClient(Swing)，大家都對Spring比較熟悉，有親近感；甚至可以考慮使用 Eclipse RCP(SWT)，因為有Eclipse在前面作為成功標桿。並且公司開發人員絕大多是Java程序員，可以隨時抽調精兵強將加入任務繁重的客戶端開發中，解決技術難題，甚至突擊編寫普通業務功能。而C#人員要重新招聘，增加了很多不確定因素。

但是采用Swing，缺點是界面比較難看，控件少得可憐，對客戶端資源的控制能力差，開發難度肯定高，並且公司內部也沒有積累（Java程序員都是做B/S應用的），並且在人力資源市場上，Swing方面但凡有點水平的開發人員工資都高得嚇人(在51Job上查了一下)；但好處就是應用服務端與客戶端都是用的Java，兩邊的人手可以靈活配置（當然前題是開發人員對於SSH和Swing都要能上手，一是需要一段時間學習，二是人家技能多了，肯定會要求加工資待遇的）。

並且Spring RichClient已經很久沒有更新了，最新的版本是1.10，還是2009年6月發布的，在開發技術日新月益的今天，這種更新速度很叫人擔心呀！難不成Spring組織已經放棄了這個子項目？！

另又看了一下Eclipse RCP，最近的更新是2009年8月的，也是叫人心里沒有底呀！

而采用C# Winform，界面好看多了，界面控件也很豐富(MS自己的，第三方的都有很多)，並且RAD開發平台是MS的絕對強項，客戶端運行速度也不錯，安裝升級很方便，人力資源市場上應用有不少儲備。但要在項目組是加入C#開發人員，對於合理組織人力資源有些不利。並且與服務端人員交流也肯定會存在問題。好在C#是Java之子，雙方有太多相似的地方，交流起來難度應當沒有想像得那樣堪比楚河漢界。

關於運行環境方面的問題，下載一個Jre，大約15M；而下載一個.net Framework大約40M。看上去.net的運行環境比Java大得多，但是要注意，從XP Sp3以后所有windows操作系統已經在安裝時集成了.net運行環境，也就是說，絕大部分用戶是不用下載.net運行環境並安裝的。

另外就是開發模式。在Java　B/S應用開發中，一般是一個程序員從數據庫、SSH到ExtJs全程貫通。好處是效率高，壞處是人員分工不明確，接口定義很隨意。

在大型應用開發中，服務端與客戶端的開發人員還是要分組比較好。服務端應當定義良好的接口，並且使用完備的測試用例保證其正確性與可用性。而客戶端開發人員則着重於用戶界面的處理，然后根據服務端的接口文檔調用即可。

其實將服務端與客戶端完全隔離開來也有其不利因素，就是人員交流成本會有相當程度的提高，服務端要為客戶端定義明晰的接口方法，提供完備的接口文檔，以方便客戶端理解與調用，並且還要為自己的服務端寫測試用例，以確保接口功能實現正確性。

但其有利因素也讓人心動，就是提高了應用系統的模塊化程度，逼迫設計人員精心划分模塊、仔細設計接口，不象以前服務端（SSH）與客戶端(ExtJs)都是一個人在做開發，很多本應當明確定義的接口，開發人員都只是按自己的意願隨意設計修改。同時，集成第三方應用時，也不用專門費時費力再開發接口，只是將已經設計實現的接口包裝一下，加上權限等對第三方的限制條件即可。

我們公司作為一家以客戶為導向的應用系統服務型公司，在技術上不應做太多、太深入研究，跟着主流和客戶的要求走就沒有錯！現在服務端的主流是什么？Java(SSH)。客戶要求客戶端不用瀏覽器，要做成桌面應用，那現在桌面應用開發的主流是什么？C#WinForm(或者WPF)。桌面應用要求跨平台嗎？不用。現在對外發布遠程應用接口的主流是什么？Web Service，那我們服務端與客戶端的通訊方式就只有采用Web Service。

看上去采用Java的長處很明顯，短處也很明顯，帶來的風險也大。而C#一切都顯得很中庸，但相應的風險也小。我們還是取中庸之道吧！Java Server+C# Client。

另外，根據同事提出的不同意見，有以下幾點說明：

1、在網絡上，開發人員公認C# Winform或者WPF的界面庫肯定比Java Swing的豐富得多。可能是概率的問題，我們運氣不好，正好沒有找到，或者沒有合適的人來進行這方面的工作；如果有可能，我們可以在下一步用WPF庫（反正.net運行環境已經安裝了）；

2、在客戶端，主要的工作是用戶界面處理，這方面不會用到復雜的C#語法與語言特性，主要是對控件的使用（界面事件的響應代碼占到60%以上），在這方面編程中，C#與Java在語法上的差別不是太明顯，要求人員通吃兩邊的難度確實不大，對Java開發人員來說，主要是學習熟練使用VS界面及界面控件；

3、關於Web Service的問題，我覺得采用Json是一種選項，實際上.net中也有原生Json處理類。但采用文本方式傳遞對象產生很多摸名其妙的問題，例如我在服務端一個應用接口中加了一個字段，或者改了字段類型、長度，如果在客戶端有幾個功能都用到了這個接口，有的可能會正常使用，有的可能會報錯，這樣給客戶端開發、調試及測試帶了很多額外負擔(困惑與不一致)。如果采用嚴格的對象接口，在調用時就會全部報錯，實際上對開發工作更加有利。並且生成接口看似增加了工作量，實際上可以一次生成，多次使用，而Json格式可能會由各個客戶端開發人員各自解析與理解，反而耽誤時間，也更有可能出錯（當然也可以寫一個中間層，統一轉換成對象接口，但增加了工作量及出錯的可能性）。客戶端Web Service接口的生成在VS中是很簡單的，可能我們沒有找到合適的方法吧？實際上客戶端應當有專門的Web Service接口處理工作崗位來統一管理配置Web Service接口，生成樁代碼、數據傳輸實體類及DLL接口庫，並提交給其他開發人員直接調用即可，這也是分層開發的要求，不過我們現在沒有設置這樣的人員崗位而已，這也是我們組建結構合理的C#開發團隊的要求之一。

4、因此，問題的根源還是在於人事。項目開始時，我們有成熟的Java框架，有熟練的開發人員，但在C#方面，沒有成熟的框架，也沒有開發人員，找了一兩個新人就開始搭建如此重要的客戶端技術框架，這完全是“事倍功半”的做法，但項目進度與人事安排的困難在那里，這也是沒有辦法的辦法。如果一開始就能找到合格的C#的技術架構師，能帶來成熟的框架（就象我們在Java服務端的），后面的問題都不會出現。

5、最后，值得高興的是，現在客戶端開發的最困難時期已經過去，不管架構好不好，我們的客戶端框架已經建起來了，也已經開發了很多實際的應用功能，並且運行也算良好，這就是一個巨大的勝利。我相信，再過一段時間，客戶端開發人員結構會日趨合理，框架也會穩定起來，好用起來，開發工作會越來越順利。