4

我试图在我的晚上和周末引导一个微型 ISV。我有一个处于开发早期阶段的应用程序。它是用 C# 编写的，主要由代表问题域的类的集合组成。此时没有 UI 或数据持久性。（我什至还没有在 .NET 平台上安顿下来。它足够早，我可以更改为 Java 或本机可执行文件）

我对这个应用程序的目标是它将是一个混合的单用户/偶尔连接的多用户应用程序。单用户部分将使用嵌入式数据库进行本地存储。这是我熟悉的开发模式。

多用户部分是我没有经验的地方。我知道每个用户都需要两件事：

  • 与公共互联网上的远程服务器进行基于 IP 的通信

  • 用户认证和远程数据存储

我知道我希望该服务器提供哪些服务（信息查找和用户到用户的交易），但除此之外，我已经不在我的范围内了。该服务器需要由第三方托管，因为我没有资源来运行我自己的服务器。请记住，在可预见的未来，我将是这个项目的唯一开发者：

  1. 哪些技术将是实现上述两件事的最简单方法？直接访问数据存储/数据库还是隔离它更好？我应该实施网络服务吗？如果是这样，SOAP 还是 REST？

  2. 迁移到多用户应用程序时，我还需要考虑哪些其他事项？我知道在多用户应用程序中安全性是一个更大的问题。尤其是当您处理任何类型的银行信息时（我会这样做）。在处理远程连接和大量用户时，性能可能是一个问题。还有什么我忽略的吗？

4

3 回答 3

2

关于迁移到多用户应用程序，集中数据当然是第一步，而实现它的最简单方法通常是使用基于云的数据库，例如 Amazon SimpleDB 或 MS Azure。您通常会获得一个访问密钥和一个用于身份验证的长“秘密”。

如果您的数据不是高度相关的，您可能需要考虑使用 Amazon SimpleDB。大多数语言都有 SDK，它允许简单的代码在世界任何地方使用密钥和秘密在 SimpleDB 数据库中存储/检索数据。您根据您的数据存储和流量为服务付费，因此进入门槛非常低，尤其是在开发过程中。它还将从一个小型家庭应用程序扩展到 amazon.com 的大小。

如果您确实选择实现自己的数据库服务器，您应该记住两个关键事项：

  1. 确保不存在会话状态，即客户端调用您的 Web 服务，发生一些操作，并且服务器忘记了该客户端（当然，除了数据库中的任何更改数据）。类似地，客户端不应该在本地保存任何可能由于来自另一个用户的交互而改变的数据。仅在本地缓存您知道不会更改（或者您不在乎它是否更改）的数据。
  2. 对于 Web 服务，每个调用通常会在其自己的线程上处理，因此您需要确保从多个线程访问数据库是安全的。如果您使用标准的 .NET 或 Java 方式与 SQL 数据库通信，则应该为您处理。但是，如果您实现自己的数据存储，这将是您需要担心的事情。

关于 REST/SOAP 等问题，一个关键的考虑应该是您想要使用什么样的平台/设备来连接到数据库服务器。例如，如果您在 .NET 中实现您的服务器，您可能会考虑使用 WCF 来实现您的 Web 服务。但是，如果您以后想要使用非 .NET 客户端，这可能会带来困难。SOAP 是一种成熟的 Web 服务技术，但实现起来相当繁琐，而且封装 SOAP 调用处理的库不一定适用于给定的客户端平台。REST 易于实现（如果您在服务器上使用 ASP.NET MVC，则非常容易），任何无需库即可处理 HTTP POST/GET 的客户端均可访问，并且易于测试，因此 REST 将是我的首选技术.

于 2010-09-13T16:29:03.940 回答
1

如果您坚持使用 .net（我的个人偏好），我会通过 WCF 公开数据访问调用。WCF 配置非常灵活且很容易上手，您需要将数据库隐藏在服务层后面。

于 2010-09-13T16:28:31.213 回答
0

1.直接访问db是最简单的，也是最差的。想想你将如何验证数据库访问......我只会编写一个带有可序列化参数的远程 API，并担心稍后连接哪些方法（Web 服务、IIOP 等） - 通信细节都已包装无论如何都隐藏起来。

2.无

于 2010-09-13T16:23:26.453 回答