提前抱歉留言！
情景：
我们正在研究为需要支持“独立”模式（桌面计算机上运行的前端+后端）的LOB应用程序选择何种技术，还要考虑本地服务器模式（本地服务器上安装的后端） ，以及通过互联网的软件即服务（后端安装在托管服务器上）。
我们希望尽量减少开发工作，这就是我们选择Silverlight前端的原因。我们打算为所有3个模型重用相同的代码库。
LOB应用程序对数据输入很重视，并会在后端进行一些数学运算。我们会有大量的意见。我们将拥有一个包含80多个表的数据库。我们目前拥有自己的DAL，使我们能够使用MSSQL，MySQL和Oracle作为DBMS。
目前的愿景是使用Agile TDD Silverlight 4.0 MVVM应用程序作为C＃中的Caliburn框架的前端。并将WCF（RIA？）服务作为后端（Non Silverlight，plain .NET 4.0）。这很适合不同的型号，因为它只是后端安装位置的问题。对于SAAS模型，我们在互联网上有一个后端可以驻留的服务器。
问题：
这听起来是否可行，或者是否认为我们可以为不同的模型提供相同的代码库？
关于后端，我们正在研究WCF RIA服务，但希望拥有“Message Security”，这在WCF的Silverlight实现中似乎是不可能的。 WCF RIA是有效的选择吗？或者说WCF在安全方面是否“更好”？
关于我们需要支持的不同DBMS。这与WCF RIA服务有关吗？或者我们最好创建自己的BLL / DAL并通过简单的WCF公开自己？
有没有人有使用内联SQL的多DBMS设置的经验，只有存储过程？原始应用程序在内联SQL上很重要，但是我们想知道这个应用程序在不同DBMS中的存储过程是如何可维护的。
最后一个问题，关于MVVM和安全性，出于安全/代码保护的原因，我们希望在后端“隐藏”尽可能多的逻辑。为此做什么是合乎逻辑的事情？我们需要做TDD，所以我们需要能够模拟模型，这意味着它需要在前端可用。但我们需要所有的逻辑都在后端。我们应该在前端使用“包装”来“链接”后端的“真实模型”吗？一种与后端模型一对一的虚拟模型。或者有更“好”的方法吗？
提前感谢您在任何这些主题中提供的任何帮助！
休伦。
答案 0 :(得分：1)
它应该是可行的，但你必须真正考虑通信模型。 SaaS场景是最具限制性和安全性的，因此您应该从那里开始并缩小到全局设置。
我建议反对RIA服务。正如MS的情况一样，它对于简单的东西很好，但你很快就会遇到它的限制然后诅咒它。有关如何在SL中执行邮件安全性的信息，请参阅here。
与问题2一样：我不会使用RIA，但即使您这样做，也可以使用Entity Framework并使其与DBMS无关。
我是一个存储过程的粉丝。是的，它会创建多个部署点（以及版本差异的固有风险），但我总是说“将SQL保留在SQL中”。
不幸的是，您所描述的是接口系统的TDD中的常见问题。我使用模型客户端测试服务器，然后使用真实服务器测试客户端。
答案 1 :(得分：0)
以下是我们最终为LOB选择的内容 - 本地/客户端 - 服务器/ saas应用程序：
事实证明这是非常可行的。对于本地，客户端服务器和saas，我们有很少的例外，大部分代码库完全相同。
我们决定不使用WCF RIA，但是为了使用常规WCF呼叫，我们使用“TransportWithMessageCredential”来保护通信。
我们正在使用Entity Framework将数据库暴露给我们的后端应用程序。我们有我们的域层和我们自定义的“实体”类，我们根据我们获得的EntityFramework类来填充。
由于我们使用的是Entity Framework，因此我们的SQL语句完全消失了。我们正在使用Linq来选择我们想要的东西。到目前为止，这工作得很好。所以没有内联SQL。通过引入单独的层（实体框架 - ＆gt;上下文类 - ＆gt; Mapper类 - ＆gt;实体类），我们具有很高的可维护性。
我们尽可能地愚弄了前端。我们在那里使用的ViewModel严格用于填充所有绑定属性，以便View可以使用数据。关于什么数据或什么是可能的所有决定都在后端完成。应用程序的整个流程由后端的Manager类运行，后者使用WCF双工连接告诉前端要做什么。