1

我从来没有构建任何东西来使用我的 Windows 窗体应用程序和 SQL Server 之间的服务。现在我有需要。

有人对从哪里开始有建议吗？或者是否有一种简单的方法可以将我的 Windows 窗体应用程序转换为在服务上运行？

到目前为止我所学的一些背景和信息：

背景

我一直在为将 SQL Server 作为服务器部分（2008 或 2012）访问的工作构建客户端服务器应用程序（.Net 4.5）。

现在公司已经表示 SQL Server 不能在 Internet 上“开放”，我们需要一个服务来运行并且该服务可以访问 SQL Server。

我们是一家大公司中唯一拥有客户可以自行访问的软件的部门。

旧的应用程序是 FOXpro 并且必须努力工作以保持多个用户的工作等。选择使用 SQL Server Express，但是虽然我们的客户可以在系统上安装 Foxpro，但不能安装 SQL Server Express（可能会丢失10-20% 的客户）。我的老板希望使用 SQL Server 为我们的客户托管数据库，这是我们一年来一直在发展的道路。我最近在应用程序中添加了实体框架（版本 5），但并非所有这些都是使用它构建的（可能 5% 使用 EF），如果这有助于找到解决方案，我认为我可以相当快地移动所有这些。

学到现在

我浏览了一堆东西，但它们都使用 OData 服务，这似乎使当前的客户端应用程序代码一文不值。基本上看起来我需要构建一个 ASP.Net Web 应用程序，而不是我们投资超过 10 万美元的 Windows 窗体应用程序。

显然这不可能，我错过了一些东西。但是在互联网上大约一个小时后，我开始吓坏了。我不清楚我是否可以使用 OData 来创建我的 Windows 窗体客户端应用程序，如果可以的话，它的外观如何。我在 OData 上看到的一切都指向构建 Web 应用程序。

再多一点背景300-500 个安装用户 - 大约 200-300 个数据库/客户端（所有客户端都有自己的数据库）。

更新 7/25/2013 当我说每个客户端都有自己的数据库时，我的意思是每个客户端都会在我们的服务器上拥有一个数据库。没有计划自助服务。旧方式是自助服务，新方式为什么不是自助服务。 2013 年 7 月 25 日结束更新

问题，再次
有人对从哪里开始有建议吗？或者是否有一种简单的方法可以将我的应用程序转换为在服务上运行？

4

1 回答 1

1

  1. 您必须选择要通过线路传递的数据传输对象类型。传统上，这一直是 DTO（数据传输对象）、（在严格的 dotnet 世界中）数据集（只是花哨的 xml）或 Xml ......并在其中添加 JSON。

  2. 您的服务将公开方法。因此，您无需与 Sql Server 对话，而是与服务对话。您的客户端应用程序应该对您选择的 RDBMS 类型一无所知。

  3. 我会选择WCF。“Web Api”也是一个新事物。有些人将其视为 WCF 的替代或升级。我有点认为他们制作了 Web Api，因为 WCF 可能很复杂，因为有很多选择。WCF 中的配置是“魔法”，一旦你做对了，它就很好，但有时会很麻烦。

  4. 如果您使用 WCF，并且您的客户端只是 DotNet 客户端，那么我将使用类型共享。这是我的第一个选择。只有当我认为我可能有一个非 DotNet 客户端时，我才会离开类型共享。

  5. 我会阅读这篇较旧的文章。

http://msdn.microsoft.com/en-us/library/Ee817644(pandp.10).aspx

如果你将“Json”加入他们的“传递什么”列表中，你会更清楚地掌握“我传递什么”的概念。“业务实体”对他们来说意味着 DTO 或 POCO 对象。

  1. 如果您的原始应用程序遵循上述 #5 的良好做法，那么您应该能够实现类型共享 WCF。我不是说它是“剪切和粘贴”，但它是可行的。

  2. 如果您的“架构”不像良好的层分离和关注点分离，那么您将处于一个受伤的世界。如果原始代码中到处都是 SqlConnection，那么您将处于一个受伤的世界。

糟糕的前期设计会让公司付出 10 倍、100 倍、100,000 倍的代价。不知道为什么有些人不明白这一点。

祝你好运伙计。

陷阱：“只需连接一些 Web 服务 asmx 页面”。那是一个常见的“补丁”。这是非常 2003 年的。这不是 2013 年的正确方法。

于 2013-07-25T13:24:20.013 回答