-1

提前为文字墙道歉！

设想：

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

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

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

当前的愿景是使用 Agile TDD Silverlight 4.0 MVVM 应用程序作为带有 Caliburn 框架的 C# 前端。并将 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，所以我们需要能够模拟模型，这意味着它需要在前端可用。但是我们需要将所有逻辑都放在后端。我们是否应该在前端使用“包装器”来“链接”后端的“真实模型”？一种与后端模型一对一匹配的虚拟模型。或者有没有“更好”的方法来做到这一点？

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

休伦。

4

2 回答 2

1

  1. 它应该是可行的，但你必须真正考虑通信模型。SaaS 场景是最严格和安全敏感的，因此您应该从那里开始并缩减到全本地设置。

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

  3. 如问题 2：我不会使用 RIA，但即使您这样做，您也可以使用实体框架并使其与 DBMS 无关。

  4. 我是存储过程的粉丝。是的，它创建了多个部署点（以及版本差异的固有风险），但我总是说“将 SQL 保留在 SQL 中”。

  5. 不幸的是，您所描述的是接口系统的 TDD 中的一个常见问题。我会使用模型客户端来测试服务器，然后使用真实服务器来测试客户端。

于 2011-03-22T12:25:46.970 回答
0

以下是我们最终为 LOB 选择的内容 - local/client-server/saas 应用程序：

  1. 结果证明这是非常可行的。我们很少有例外，大部分代码库是完全相同的，用于本地、客户端服务器和 saas。

  2. 我们决定不使用 WCF RIA，而是使用常规 WCF 调用，我们使用“TransportWithMessageCredential”来保护通信。

  3. 我们正在使用实体框架将数据库公开给我们的后端应用程序。在那里，我们有我们的领域层和我们的自定义“实体”类，我们根据我们获得的 EntityFramework 类来填充它们。

  4. 由于我们使用的是实体框架，我们的 SQL 语句完全没有了。我们正在使用 Linq 来选择我们想要的内容。到目前为止，这工作得很好。所以没有更多的内联SQL。并且通过引入单独的层（实体框架 -> 上下文类 -> 映射器类 -> 实体类），我们具有很高的可维护性。

  5. 我们尽可能地简化了前端。我们在那里拥有的 ViewModel 严格用于填充所有绑定属性，因此 View 可以使用数据。所有关于什么数据或什么是可能的决定都在后端完成。应用程序的整个流程由后端的 Manager 类运行，该类使用 WCF Duplex 连接来告诉前端要做什么。

于 2012-03-08T11:43:42.220 回答