帶有業務邏輯的視圖vs代碼

對於一個應用程序，我需要每小時向最終用戶發送個性化的邀請電子郵件。這些用戶的電子郵件地址和其他信息都在數據庫中。帶有業務邏輯的視圖vs代碼

具有一個位 Planned.IsPlannable集到True和所有用戶都具有一個Planned.DateStart和一定週期之間的 Planned.DateEnd可用於接收電子郵件消息。
約有350條消息發送每小時。
消息中必須包含的所有信息是數據庫中的。
的應用程序是一個 .NET4.0控制檯應用程序，數據訪問我用Subsonic3.0。

至少有兩種情況可供選擇：通過檢索相應的數據

1 :)查看類似：

SELECT [Computer].ComputerName, 
      [User].UserEmail, 
      [Planned].DateAvailable, 
      [Planned].DatePlanned 
FROM  [Computer] 
INNER JOIN 
      [Planned] ON [Computer.ComputerID] = [Planned.ComputerID] 
INNER JOIN 
      [User] ON [Computer].UserID = [User].UserID 
WHERE  (DATEDIFF(dd, GETDATE(), [Planned.DateAvailable]) < 10) 
      AND Planned.IsPlannable = 1

和組成的基礎上，此視圖的結果，此應用程序的C＃代碼中的相應消息。

2 :) 視圖構造SQL服務器上整個消息和返回類似

[EmailTo] [Subject] [Body]

然後僅遍歷槽的結果以及從它
創建MailMessage對象
在這兩種情況下我得到的消息，如：

foreach (vwGetInvitableComputer u in UserController.GetAllInvitableUsers()) { // where the usercontroller wraps the Subsonic logic. // the composition happens here }

對C＃代碼中的迭代槽進行迭代，並僅從該預先格式化的數據組成郵件消息。

什麼情況下性能和資源明智選擇？

更新：確實是有文本操作數據庫的選項。然而，這是在messagbody到CompterName，DateStart和DateEnd.Perhaps更換三根弦，SQL-意見有足夠的智慧來傳播性能爲此，雖然C＃代碼「請求時」做到了嗎？

來源

2011-06-15 Caspar Kleijne

「傳播表現」是什麼意思？你的意思是跨線程嗎？您可以在C＃中輕鬆地使用並行foreach或其他東西。 – 2011-06-15 13:11:56

首先考慮：你能想象更改郵件格式的必要嗎？如果不是那麼它可能沒有關係。

第二個考慮：你能想象一個時間，電子郵件需要更多的操作而不是SQL很容易實現嗎？如果是這樣，那麼你絕對應該選擇C＃。

第三個考慮：重新部署對環境有多大的問題？

最後是一個替代選項：使用C＃作爲消息組合，但使用基於數據庫或基於文件的模板，可以輕鬆更新。

來源

2011-06-15 12:58:21

我知道這是一個有風險的問題，但我想知道是否有人有過這方面的經驗。然而，你的考慮是好的，我堅持把我的BL放在應用中，而不是在DB中。 – 2011-06-16 05:54:24

我會選擇選項2，組成使用視圖或存儲過程在服務器上傳送電子郵件所需的所有信息。理想情況下，數據庫調用應儘可能減少往返服務器的次數。

來源

2011-06-15 12:53:02 DaveRead

我認爲這是不好的建議。這是不需要的限制優化。在他的兩個示例選項（如果他一舉獲得所有數據）中將訪問相同數量的服務器。 SQL中的組合比C＃更難（容易出錯）。 – 2011-06-15 13:00:52

很明顯，我正在設想某種模板系統，如您的答案中所述;） – DaveRead 2011-06-15 13:12:40

帶有業務邏輯的視圖vs代碼

回答

相關問題