繼KISS principle通信,我突然意識到如下:KISS:簡單的C#應用程序與RESTful Web服務
- 在.NET中,可以使用實體模型框架環繞的數據庫。
- 該模型可以通過WCF作爲Web服務公開。
- 此Web服務將有一個非常標準化的定義。
- 可能會創建一個客戶端應用程序,它可能會使用任何此類RESTful Web服務。
我不想重新發明輪子,如果有人已經做到了這一點,所以我的問題很簡單,它不會讓我感到吃驚:有沒有人已經創建了一個簡單(臺式機,不是web)客戶端應用程序可以使用基於Entity Framework的RESTful服務,並允許用戶直接讀取和寫入數據到此服務?
否則,我只需要自己「發明」這個。 :-)
問題是,數據庫層和RESTful服務已經完成。 RESTful服務只會在開發階段留在項目中,因爲我們可以直接使用圍繞它構建的Web應用程序來使用數據庫層組件。在部署Web應用程序時,RESTful服務僅保留在部署之外。
但是數據庫有大量的數據要管理近50個表。在針對本地數據庫進行開發時,我們可以直接訪問數據庫,因此我不需要此工具。部署完成後,Web應用程序將成爲訪問數據的唯一方式,因此我無法使用此工具。但是我們也有一個測試階段,其中數據庫存儲在本地域之外的另一個系統上,並且此數據庫不適用於開發人員。只有管理員可以直接訪問這個數據庫,使測試更復雜一些。
但是,通過RESTful服務,我仍然可以直接訪問數據。因此,當某些測試出錯時,我可以通過此連接修復數據,或者僅在本地系統上創建測試數據的副本。還有很多其他功能,甚至可以直接在Excel或XMLSpy中打開表格服務的URL以查看內容。但是當我想回寫一些東西時,我必須編寫特殊的代碼才能做到這一點。使我能夠訪問數據並對其進行修改的通用工具將更容易。由於它是圍繞ADO.NET數據服務的通用設置,因此這也應該很容易。
因此,我可以做到這一點,但希望別人已經做了類似的事情。但看起來目前還沒有這樣的工具...
客戶端不應該知道有關數據庫結構的任何信息。 dataservices返回一個atom feed,它列出了所有表格,可以顯示在組合框中。選擇一個表格,它會從這個表格中返回數據,這可以通過網格顯示,只需要從「d」命名空間中取出元素即可。其他功能不應該那麼難,因爲數據服務已經將其大部分推廣了。危險嗎?是。但作爲一個內部工具仍然實用。 (安全問題需要在服務中處理,而不是在應用程序中處理。) – 2009-09-18 10:00:02
儘管您的示例有效,並且應用程序可以工作,但在商業環境中幾乎沒有什麼意義。現實是你永遠不會向最終用戶顯示錶格的所有字段。另外,這將是非常通用的。所以我支持我的回答。在您的**環境**中,它可能是實用的,但除了創建CodePlex項目之外,我還沒有看到任何此類客戶端。 – BinaryMisfit 2009-09-18 10:21:52
在商業環境中,沒有。但在開發環境中,您希望快速瀏覽數據,這種工具非常實用。 – 2009-09-18 10:35:49