帶獨立和軟件即服務模型的LOB App技術選擇

Question

對不起，對於文本牆！

場景：

我們正在尋找什麼樣的技術對於需要支持「獨立」模式（前端+後端臺式機上運行），而且本地服務器模式下的LOB應用來選擇（後端安裝在本地服務器上），以及通過互聯網的軟件即服務（安裝在託管服務器上的後端）。

我們希望儘量減少開發工作，這就是我們選擇Silverlight前端的原因。我們打算爲所有3個模型重新使用相同的代碼庫。

LOB應用程序在數據輸入上很沉重，並且會在後端做一些數學工作。我們會有大量的意見。我們將有一個包含80多個表格的數據庫。我們目前擁有自己的DAL，使我們能夠使用MSSQL，MySQL和Oracle作爲DBMS。

目前的願景是在C＃中使用Agile TDD Silverlight 4.0 MVVM應用程序作爲Caliburn框架的前端。並將WCF（RIA？）服務作爲後端（非Silverlight，純.NET 4.0）。這很適合不同的型號，因爲這只是後端安裝位置的問題。對於SAAS模型，我們在互聯網上有一臺後端可以駐留的服務器。

問題：

1. 這聽起來是可行的，在所有的，或者是whishfull思想，我們可能對不同車型相同的代碼庫？

2. 關於後端，我們正在研究WCF RIA服務，但希望擁有「消息安全性」，這在WCF的Silverlight實現中似乎不可行。 WCF RIA是一個有效的選擇嗎？或者WCF以任何方式在安全方面「更好」？

3. 關於我們需要支持的不同DBMS。這是可行的WCF RIA服務？或者，我們是否更適合創建自己的BLL/DAL，並通過簡單的WCF展示自己？

4. 有沒有人有沒有使用內聯SQL的多個DBMS設置的經驗，只是存儲過程？最初的應用程序在內聯SQL上很沉重，但我們想知道如何在不同的DBMS中只用Stored Procedures來維護這個應用程序。最後一個問題，就MVVM和安全性而言，爲了安全/代碼保護的原因，我們希望在後端「隱藏」儘可能多的邏輯。這將是一個邏輯的事情嗎？我們需要做TDD，所以我們需要能夠模擬模型，這意味着它需要在前端可用。但是我們需要所有的邏輯在後端。我們是否應該在前端使用「包裝器」來「鏈接」後端的「真實模型」？一種適合後端模型的1對1虛擬模型。還是有一種「更好」的方式來做到這一點？

在此感謝您提前給予我們任何這些科目的幫助！

Huron。

Answer 1

1. 它應該是可行的，但你必須真正考慮通過通信模型。SaaS方案是最具限制性和安全性的方案，因此您應該從此開始並縮減爲全部本地設置。

2. 我建議對RIA服務。通常情況下，MS對於簡單的東西來說很好，但你很快就會遇到它的限制，然後詛咒它。請參閱here瞭解如何在SL中執行Message Security。

3. 與問題2一樣：我不會與RIA一起使用，但即使您這樣做，也可以使用Entity Framework並使其與DBMS無關。

4. 我是一個存儲過程的粉絲。是的，它創建了多個部署點（以及版本差異的固有風險），但我總是說「SQL中保留SQL」。

5. 不幸的是，您所描述的是接口系統的TDD中常見的問題。我會使用一個模擬客戶端來測試服務器，然後使用真實的服務器來測試客戶端。

Answer 2

下面是我們最終選擇了我們的LOB - 本地/客戶端 - 服務器/ SaaS的應用程序：

1. 事實證明，這是非常可行的。我們只有極少數例外，對於本地，客戶端服務器和saas，大部分代碼庫都是完全相同的。

2. 我們決定不使用WCF RIA，而是使用常規的WCF調用，我們使用「TransportWithMessageCredential」來保護通信。

3. 我們使用實體框架將數據庫公開給我們的後端應用程序。在那裏，我們有我們的域名層和我們自定義的「實體」類，填寫基礎上的EntityFramework類我們得到的。

4. 由於我們使用實體框架，我們的SQL語句都完全沒了。我們正在使用Linq來選擇我們想要的。到目前爲止，這工作很好。所以沒有更多的內聯SQL。通過引入單獨的層（實體框架 - >上下文類 - >映射類 - >實體類），我們有一個高可維護性。

5. 我們儘可能地減少了前端。我們在那裏的ViewModel嚴格用於填充所有綁定屬性，以便View有數據可用。所有關於什麼數據或什麼是可能的決定都在後端完成。應用程序的整個流程由在使用WCF雙工連接告訴前端做什麼後端Manager類運行。