實體框架，WCF，客戶機和對象上下文質疑

Question

應用目的：
我創建將負責許多過程的應用程序，但我目前正在建設一個價格給料機，以此來拯救這些價格，功能將這些價格發送到客戶端應用程序（作爲概念驗證）。這些價格將被映射到稱爲「安全分析」和「安全價格日誌」的實體。這兩個實體具有相同的屬性，但日誌會記錄收到的每個價格，分析只是保存每個安全性的最新數據。

我目前正在嘗試確定完成此操作的最有效和最穩定的方式。要求/這obstables是：

• 價格出現非常頻繁（有時會收到多個價格每秒）
• 客戶的需要實時數據
• 價格需要被保存到數據庫每次他們來時在

架構：
我belieive本申請適合向n層體系結構。我想包括在各層（原諒我的這些命名）：

• 實體層：其中模型構建
• 「工廠」：這會包含我的供稿（將有約10），用於處理數據的邏輯，數據到實體的轉換以及允許將數據暴露給客戶機
• 客戶機層：我希望工廠公開數據合同，以允許客戶機使用數據合同中的實時數據廠。我做了一些研究，我將使用發佈 - 訂閱設計模式

因此，所有這一切的背景資料，在這裏漫步是我的問題通過WCF Web服務完成此：

• 有什麼缺點有一個長期運行的對象上下文？ （我一直在閱讀，我不應該這樣做，但沒有人明確地說爲什麼或給出了替代品，將爲我工作）
• 如果我不斷創建新的上下文，是我已經拉入到以前的上下文中可用的數據一個新的上下文？我擔心當我向客戶推送數據並處理許多新價格時，我會經常從數據庫中提取數據。
• 我目前使用自我跟蹤的實體，並認爲他們是這個應用程序的正確選擇，但如果任何人有任何問題或他們可以提供的智慧，這將不勝感激。
• 最後，創建我的「工廠」最好的項目類型是什麼？它將運行在IIS服務器上，我希望它接受我的所有數據饋送，並讓客戶端接受不同的和複合的（來自多個饋送）數據。我傾向於一個WCF服務應用程序，因爲它可以讓我輕鬆地派生服務合同，但我不確定這是否是正確的選擇。

任何幫助，您可以提供與此表示讚賞。另外，我對此的長度表示抱歉，我對於實體框架是如何工作以及應該從哪裏開始感到失望。謝謝！

編輯：感謝您的回覆所有人。我現在必須轉向其他方面，但本週晚些時候我會有機會回顧這些。

Answer 1

您使用發佈/訂閱模型的想法很好。但是，您不需要不斷地提取數據。

您的所有客戶都成爲聽衆。 新價格出現時的推送事件包括事件參數模型中的價格變化。 不確定您是否需要「工廠」型號。

對於實體框架來說，短期上下文總是最好的方式。儘管您可以在很短的時間內創建很多，但框架會從連接池中檢索它們。

每個上下文都持有到數據庫的連接，該數據庫始終被視爲一種罕見資源。你應該在最短的時間內挖掘稀有資源。

當你創建一個新的上下文，並且你傳遞了一個對象時，你會發出一個Attach來重新綁定對象到上下文。它實際上綁定到對象所在的相應表格。

您的WCF服務是最好的和最高性能的方式。但不是工廠，你基本上是在寫服務。

對於你的客戶： 在啓動時調用serviceContext.GetInitialPrices，你會得到所有的價格爲那一刻的。 訂閱獲得價格變動

爲您服務： 每當價格變化的源打你： 創建上下文 連接上下文每個價格記錄 調用的SaveChanges

Publish changes of the array of prices that have changed. 

你更大的問題則是決定你將用於發佈/訂閱的內容。

Answer 2

這聽起來非常直截了當，如果你擔心做太多的數據庫調用，你必須考慮在你的中間層和可能在客戶端上緩存數據。

如果你正在考慮使用實體框架，這聽起來像個好主意。在我工作的商店裏，我們不使用微軟最新的.net玩具;一旦我掌握了Entity Framework，我幾乎不能相信我的數據層變得多簡單了。它會爲您自動執行數小時冗長的，容易出錯的數據層編程。

Answer 3

你的問題太複雜了。這類問題通常沒有令人滿意的答案，因爲它太開放，而且還需要對您的需求進行更深入的分析。

你的子問題，談幾點想法：

• 長期運行的情況下可以顯著問題。它有一個lot of disadvantages（每個上下文單個共享實例，每個上下文單個共享工作單元，而不是線程安全），所以確保在你真正選擇使用它之前考慮所有這些實例。長時間運行的上下文仍然可以作爲單一工作單元使用 - 這通常發生在厚的客戶端，其中您的上下文與您的UI窗口一樣長。
• 否。從一個上下文中提取的數據必須手動附加到另一個上下文或再次從數據庫加載。它們不會自動跟蹤新的上下文實例，但不清楚爲什麼您因爲下一個問題而擔心這個問題。
• STE有他們的pros and cons。他們可以solve quite complex problems但他們在同一時間緊緊地耦合您的客戶和服務。當您傳輸對​​象圖時，它們也可以顯着增加傳輸的數據量，因爲假定的方案是獲取對象圖並將該圖返回到服務中，即使您僅更改了單個關係。 I'm not big fan of STEs。
• Pub-Sub模式和您的實時數據要求：這是應該使用一些更適合的技術。我以前使用過JMS（除非您使用來自某些JMS提供程序（如IBM XMS或Apache NMS）的API的JMS（不能直接在.NET中提供）/ Tibco EMS和Tibco Randezvous，並且如果我將WCF中可用的Pub-Sub模式與實際的Pub-Sub基礎結構WCF的實現就像一個糟糕的玩笑。太複雜，太慢而且有很多缺陷，因爲它缺少消息中間件。如果您的應用程序對業務至關重要，那麼您的預算（或使用某些消息傳遞解決方案的現有企業基礎架構）具有良好的性能，並且您的實時數據要求很嚴格，因此應該調查這些可能性我還沒試過，但RabbitMQ也應該提供Pub-Sub基礎設施。