具有独立和软件即服务模型的 LOB 应用程序的技术选择 [关闭]

Question

提前对文字墙表示歉意！

场景：

我们正在研究为需要支持“独立”模型（在台式机上运行的前端 + 后端）和本地服务器模式（安装在本地服务器上的后端）的 LOB 应用选择什么技术，以及通过 Internet 提供的软件即服务（后端安装在托管服务器上）。

我们希望最大限度地减少开发工作，这就是我们选择 Silverlight 前端的原因。我们打算为所有 3 个模型重复使用相同的代码库。

LOB 应用需要大量的数据输入，并且会在后端进行一些数学运算。我们会有大量的意见。我们将拥有一个包含 80 多个表的数据库。我们目前拥有自己的 DAL，使我们能够将 MSSQL、MySQL 和 Oracle 用作 DBMS。

当前的愿景是使用 Agile TDD Silverlight 4.0 MVVM 应用程序作为 C# 中的前端和 Caliburn 框架。并将 WCF（RIA？）服务作为后端（非 Silverlight，纯 .NET 4.0）。这很适合不同的模型，因为这只是后端安装位置的问题。对于 SAAS 模型，我们在 Internet 上有一个服务器可以驻留后端。

问题：

1. 这听起来完全可行，还是认为我们可以为不同的模型拥有相同的代码库？

2. 关于后端，我们正在研究 WCF RIA 服务，但希望拥有“消息安全”，这在 WCF 的 Silverlight 实现中似乎是不可能的。 WCF RIA 是一个有效的选择吗？还是说普通 WCF 在安全方面“更好”？

3. 关于我们需要支持的不同 DBMS。这对 WCF RIA 服务可行吗？还是我们最好创建自己的 BLL/DAL 并通过普通 WCF 公开它？

4. 有没有人使用过不使用内联 SQL，只使用存储过程的多 DBMS 设置的经验？原始应用程序大量使用内联 SQL，但我们想知道仅使用不同 DBMS 中的存储过程，该应用程序的可维护性如何。

5. 最后一个问题，关于 MVVM 和安全性，出于安全/代码保护的原因，我们希望在后端“隐藏”尽可能多的逻辑。对此做什么是合乎逻辑的？我们需要做 TDD，所以我们需要能够模拟模型，这意味着它需要在前端可用。但是我们需要将所有逻辑都放在后端。我们是否应该在前端使用“包装器”来“链接”后端的“真实模型”？一种与后端模型一对一匹配的虚拟模型。或者有没有“更好”的方法来做到这一点？

提前感谢您在这些主题中为我们提供的任何帮助！

休伦。

Answer 1

1. 它应该是可行的，但你必须认真考虑通信模型。 SaaS 场景限制性最强且对安全性最为敏感，因此您应该从那里开始并缩减到全本地设置。

2. 我建议不要使用 RIA 服务。与 MS 的情况一样，它对于简单的东西来说很好，但你很快就会遇到它的限制，然后诅咒它。请参阅here 了解如何在 SL 中进行消息安全。

3. 如问题 2：我不会使用 RIA，但即使你这样做，您也可以使用实体框架并使其与 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 可以使用数据。所有关于什么数据或什么是可能的决定都在后端完成。应用程序的整个流程由后端的 Manager 类运行，该类使用 WCF Duplex 连接来告诉前端要做什么。