我正尝试在晚上和周末启动微型 ISV。我有一个处于开发早期阶段的应用程序。它是用 C# 编写的，主要由表示问题域的类集合组成。此时没有 UI 或数据持久性。 (我什至还没有确定 .NET 平台。它还早到我可以更改为 Java 或 native 可执行文件)
我对这个应用程序的目标是它将成为一个混合的单用户/偶尔连接的多用户应用程序。单用户部分将使用嵌入式数据库进行本地存储。这是我熟悉的开发模式。
多用户部分是我之前没有经验的地方。我知道每个用户都需要两件事:
我知道我希望此服务器提供哪些服务(信息查找和用户到用户交易)，但除此之外我不在我的元素范围内。服务器需要由第三方托管，因为我没有资源来运行自己的服务器。请记住，在可预见的 future ，我将是该项目的唯一开发人员:
哪些技术是实现上述两件事的最简单方法？直接访问数据存储/数据库还是隔离它更好？我应该实现网络服务吗？如果是这样，SOAP 还是 REST？
在迁移到多用户应用程序时，我还需要考虑哪些其他事项？
我知道在多用户应用程序中安全性是一个更大的问题。特别是当您处理任何类型的银行信息时(我会)。在处理远程连接和大量用户时，性能可能是一个问题。还有什么我忽略的吗？
关于迁移到多用户应用程序，集中数据当然是第一步，实现它的最简单方法通常是使用基于云的数据库，例如 Amazon SimpleDB 或 MS Azure。您通常会获得一个访问 key 和一个用于身份验证的长“ secret ”。
如果您的数据不是高度相关的，您可能需要考虑使用 Amazon SimpleDB。大多数语言都有 SDK，它允许简单的代码使用 key 和 secret 在世界任何地方存储/检索 SimpleDB 数据库中的数据。您根据数据存储和流量为服务付费，因此进入阈值非常低，尤其是在开发过程中。它还可以从小型家庭应用程序扩展到 amazon.com 的规模。
如果您确实选择实现自己的数据库服务器，您应该记住两个关键事项:
- 确保不存在 session 状态，即客户端调用您的网络服务，发生某些操作，服务器忘记该客户端(当然数据库中任何更改的数据除外)。同样，客户端不应在本地保存任何可能因其他用户交互而更改的数据。仅在本地缓存您知道不会更改(或者您不关心它是否更改)的数据。
- 对于网络服务，每个调用通常都在其自己的线程上处理，因此您需要确保从多个线程访问数据库是安全的。如果您使用标准的 .NET 或 Java 方式与 SQL 数据库对话，这应该为您处理。但是，如果您实现自己的数据存储，这将是您需要担心的事情。
关于REST/SOAP等问题，一个关键的考虑应该是你想用什么样的平台/设备来连接数据库服务器。例如，如果您在 .NET 中实现您的服务器，您可能会考虑使用 WCF 来实现您的 Web 服务。但是，如果您以后想要使用非 .NET 客户端，这可能会带来困难。 SOAP 是一项成熟的 Web 服务技术，但实现起来相当繁重，并且包装 SOAP 调用处理的库可能不一定适用于给定的客户端平台。 REST 易于实现(如果您在服务器上使用 ASP.NET MVC，则非常容易)，任何可以处理 HTTP POST/GET 的客户端都可以访问，而无需库，并且易于测试，因此 REST 将是我的首选技术.