2011-03-29 80 views
5

當考慮將面向服務的體系結構與利用SQL在查詢數據時優化性能的優秀UI結合使用時,我感到有些震驚。用SQL查詢Web服務

例如,ASP.NET的DevExpress網格視圖非常酷,它將所有過濾,排序和分頁邏輯委託給數據庫服務器。但是,這假定從具有SQL能力的數據庫服務器檢索到的數據

如果我想在數據庫和UI層之間引入Web服務層,並讓UI使用Web服務來查詢數據,該怎麼辦?

  • 如何設計Web服務和UI,以便我可以通過Web服務將過濾請求從UI傳遞到數據庫?
  • 我是否需要提供List QueryData(string sqlQuery)樣式的Web服務,並且必須自行解析SQL字符串以確保安全/訪問限制?
  • 或者有沒有什麼好的框架或設計指導方針來承擔我的這個負擔?

這一定是一個非常普遍的問題,我相信它已經解決得比較充分了,對嗎?

我主要感興趣的是基於.NET/C#的或兼容的解決方案。

編輯:我找到了OData和Microsoft WCF Data Services。如果我是正確的,基於OData的應用程序可以看看如下:

  1. 用戶 --- /給我1(記錄1..10)/ --->ASP.NET服務器控制(當然,經由HTTP)
  2. ASP.NET服務器控制 ---/LINQ查詢/ --->數據服務客戶端
  3. 數據服務客戶端 ---/OData的查詢/ --->WCF數據服務
  4. WCF數據服務 ---/LINQ查詢/ --->實體框架
  5. 實體框架 ---/SQL查詢/ --->數據庫

如果我有這個權利,我的DevExpress服務器控件應該能夠委託一個過濾請求(例如只給我前10名)通過所有這些層到數據庫,然後使用它的索引等來執行該查詢。

是嗎?

編輯︰看到這個線程來生活是一種喜悅:-)很難決定接受什麼答案,因爲所有對我來說似乎同樣好......

+0

你確定你不是「只是」需要實現IQueryable並使web服務調用到後端?不熟悉組件... – 2011-03-29 07:03:06

+0

不錯的問題,我一直在努力,但從來沒有想出一個優雅的解決方案。在之前的實現中,我提供了一個自定義的「過濾器」參數給我的服務方法(最終被解析爲WHERE子句),然後在服務中添加了一些額外的標準以確保訪問限制。編輯:在這種情況下,我與Telerik Grid一起工作,它生成過濾器作爲OQL查詢 – Ozzy 2011-03-29 07:23:34

+0

@Vincent:實現IQueryable可能是故事的一部分,但小事一樁:它允許在表示層上使用LINQ,但它沒有解決(?)如何將過濾和排序委託給DBMS的問題。 – chiccodoro 2011-03-29 15:03:57

回答

1

執行List QueryData(string sqlQuery)會使您面臨無限數量的安全問題。

如果您需要根據安全訪問權限進行過濾,那麼OData實現也不是微不足道的,您需要在WCF服務上設置適當的授權/驗證,以便您可以根據經過驗證的用戶進一步過濾OData查詢數據。

當從WCF服務中檢索數據時,實現服務器端數據操作的最簡單方法是在後面的代碼中攔截Grid的排序/篩選操作,然後根據什麼調用WCF服務的專用方法用戶在做。

+0

儘管你仍然需要在服務器端實現某種認證和授權機制。服務器端不能因僞造其他人的請求而被愚弄。 – 2011-07-13 09:18:30

2

真的很有趣的問題!我不認爲有正確或錯誤的答案,但我認爲你可以建立一些架構原則。

首先,「面向服務的體系結構」是一種架構風格,它要求您公開業務服務以供其他應用程序使用。運行數據庫查詢不是一項服務 - 至少在我看來。事實上,提供執行任意SQL的Web服務可能是一種反模式 - 您可能會繞過大多數數據庫服務器提供的安全模型,您無法控制查詢 - 編寫語法正確的「選擇」查詢哪些數據庫癱瘓(笛卡爾連接是我最喜歡的),並且Web服務協議的開銷會使這種方法比通過正常訪問路由查詢數據庫要慢幾倍 - LINQ或其他。

因此,讓我們假設您接受該觀點 - 問題的解決方案是什麼?首先,如果您想要使用DevExpress網格的生產力,您可能應該以DevExpress希望您工作的方式工作 - 如果這意味着直接查詢數據庫,那麼這是迄今爲止最好的方法。如果您想要轉移到SOA,並且DevExpress網格不支持該功能,那麼應該找到新的網格控件,而不是將整個企業體系結構定製爲相對較小的組件。

其次 - 在結構上,你應該在哪裏進行排序,過濾等?這在SQL中是一個簡單的概念,但在嘗試將其轉換爲Web服務規範時感到不愉快 - 您很快就會得到一個難以理解的方法簽名(「getAccountDataForUser(userID,bool sortByDate,bool sortByValue,bool filterZeros,bool filterTransfers)」 )。另一方面,對客戶端執行過濾和排序是混亂和緩慢的。

我的建議是查看Specification Pattern - 這可以讓您擁有乾淨的方法簽名,但可以以一致的方式指定所需的排序和排序。

+0

我接受你的觀點。 OData規範看起來有點像對這個問題的答案。它不允許任意的SQL查詢,但支持過濾和排序。它甚至可能與DevExpress等組件兼容(但我仍然懷疑,從未嘗試過)。 – chiccodoro 2011-07-13 12:06:28

1

「這肯定是一個很普遍的問題,我肯定它已經被解決得比較充分了,對吧?」

鑑於圍繞開發者世界的皮膚貓的數量,我不得不說。

WCF數據服務提供了迄今爲止我發現的最佳解決方案,但驗證和授權可能會非常棘手。有一個體面的帖子,涵蓋了圍繞此的服務器端問題http://blogs.msdn.com/b/astoriateam/archive/2010/07/19/odata-and-authentication-part-4-server-side-hooks.aspx。設置這個並不容易,但它確實很好。