我应该如何从桌面应用程序与数据库交互，而不向全世界打开它
本文关键字：全世界 交互 桌面 应用程序 数据库 我应该 | 更新日期: 2023-09-27 18:18:30
基本上，我和我的团队正在开发一个新的桌面应用程序，它将在我们生产车间的Windows 7桌面上运行。该程序在引入时将被大量使用，并且需要与我们的制造数据库进行交互。我估计(最终)会有大约100 - 200台机器同时运行这个应用程序。
我们很幸运，我们可以从头开始做所有的事情，所以我们定义了数据库，任何web服务，程序设计，以及前面提到的任何交互。
现在，我们的遗留应用程序只能直接访问数据库，这很棘手。我们不希望在新应用程序中这样做。
我的问题是，我该怎么做?模糊，我知道，但基本上我在这里有很多可以支配的，我不完全确定正确的方向是什么。
我最初的想法，基于我看到别人在做什么，基本上是通过使用web服务隔离数据库。也就是说，所有来自底层的数据库交互都必须通过web服务进行，通过关闭数据库逻辑来提供一层安全。然后，通过活动目录对单个用户保护web服务调用。
正如我所发现的，这有它自己的一些含义…我们必须在数据到达应用程序之前对其进行抽象。通过反复使用web服务调用来破坏或垃圾数据，仍然存在恶意滥用的可能性。我们已经看了实体框架，真的很喜欢它提供的东西，但据我所知，在这个实例中，当我们在应用程序级别时，它将不可用。我似乎无法得出什么是"正确"的结论。那么，什么是正确的呢?
WebServices听起来是一种正确的方法。在web服务层上实现面向soa的层使您可以对数据库服务器上的数据发生的情况进行大量控制。
我不太同意你对重复电话造成任何损害的怀疑——首先，你可以对每个电话都有一个审计日志，这样就可以很明显地发现可能的滥用。但是您也可以实现基于角色的安全性，以便将web服务方法暴露给角色中的用户，这意味着不是每个人都可以调用任何方法。
你甚至可以用表单身份验证来保护你的web服务，这样身份验证就可以针对任何数据源完成，而不仅仅是活动目录。
最后一件事，应用程序本身可以作为ClickOnce应用程序发布，这样它就可以从网页上下载并执行，它会自动更新自己，就像你发布新版本一样。
如果你需要一些技术指导，我多年前就写过了:
http://netpl.blogspot.com/2008/02/clickonce-webservice-and-shared-forms.html既然你是新手，我的建议是在Servicestack中使用API包装器方法。
查看:http://www.servicestack.net/ServiceStack.Northwind/
这样做，你可以使用服务栈身份验证，抽象出你的db层(因为你可以移动到不同的db提供商，改变它的位置，为工作项提供队列等)，并及时将你的整个基础设施移动到内部intranet应用程序。
Plus Servicestack非常快，几乎可以与任何协议互操作，并提供通过MONO运行它，所以你不会被一个非常昂贵的MS后端所困扰。
我的两分钱。:)首先这个问题不适合StackOverflow，你可能很快就会得到接近的投票。
第二，你可能想看看WCF RIA服务。
这些将允许您为所有实体创建基本的CRUD操作，以及类似的东西。我自己从来没用过这个，不，我不确定潜在的问题是什么。
否则，就照我们做的做:
创建通用(<T>)接口、服务和契约等等。这将允许你在你的服务、dao、视图模型和类似的任何实体类型中调整你的CRUD功能。