经验之谈：MySQL与ASP.NET配合更强大[2]

Posted 2023-05-10

参考技术A

　　 连接 MySQL 数据库

　　使用mysql数据库的第一步是要通过MySQLConnection类和数据库建立连接 通过一个连接字串 MySqlConnection 将会被实例化成一个示例 连接字符串将告诉代码到哪里去找MySQL服务器以及其他一些选项

　　一个连接字串告诉代码使用指定的用户名和密码去连接一个名为MySQLTestServer的MySQL服务器 并进入techrepublic数据库 我在我的测试机上设定了允许匿名登陆(这样的设定有非常大的安全漏洞 所以不建议你在生产服务器上也这么做) 所以在范例中将会使用如下的连接字串:

　　 server=localhost; database=sitepoint;

　　指定了连接字串后 MySqlConnection 对象的Open方法就被调用并打开连接 连接建立后 你就可以给MySQL数据库发送命令或从数据库获得数据了

　　 ASP NET和MySQL的组合

　　让我们更深入的讨论一下结合MySqlConnection类和其他的类来生成一个MySQL服务器上的数据库列表 表 B列出了一个使用C#写的ASP NET的网页表单 它建立了一个连接 接着给服务器下了一个指令(SHOW DATABASES) 然后通过MySqlReader对象把结果显示出来

　　用 MySqlCommand 对象向MySQL服务器发送 SHOW DATABASES 命令和直接在 MySQL 管理工具中输入这个命令得结果是一样的 唯一的区别是 我们在代码中必须使用另一个对象来获取结果集 MySqlDataReader 对象在获取结果时被实例化(通过 MySqlCommand 类的 ExecuteReader 方法) MySqlDataReader 对象的 GetString 方法被用于通过ASP NET的标签控制来显示结果集中的数据 GetString 方法的指针 指定了显示结果集的当前行(在while循环中)的第一列数据

　　 Mono提示

　　如果你使用开放源代码的Mono开发平台 例子中的代码只需要做小小的改动就能正常的运行 MySQL的数据接口在 ByteFX Data MySqlClient 这个空间名里 而不是Windows上的MySql Data MySqlClient空间名 事实上 MySQL 的数据接口原来是由 ByteFX公司开发的 但是后被MySQL公司收购 所以如果你使用Mono的话 你必须这样声明空间名:

　　using ByteFX Data MySqlClient;

　　 结语

　　MySQL 和 NET 的组合提供了一个强大的开发平台 MySQL在开源社区得到了强大的技术支持 NET也通过 Mono 而被开放源代码社区所接受 这样的组合提供了一个在Windows 及其他语言如UNIX或Linux 环境下高度灵活的开发平台

lishixinzhi/Article/program/net/201311/15424

强大的自托管服务器的最佳选择：WCF 与 ASP.NET Web Api

【中文标题】强大的自托管服务器的最佳选择：WCF 与 ASP.NET Web Api

【英文标题】：Best choice for robust self hosting server: WCF vs. ASP.NET Web Api

【发布时间】：2012-04-30 10:39:08

【问题描述】：

我们目前有一个 .NET 4 应用程序，它由在后台运行的 Windows 服务和本地或远程客户端（通常只有 1-3 个）组成。

客户端有一个 WPF GUI，需要一些来自 Windows 服务的数据。因此，我们将 WCF 与 NamedPipe 绑定用于本地客户端，将 NetTcp 绑定用于远程客户端。这可行，但我们经常遇到无法访问的端点（通道故障或未找到等）的问题。我们已经尝试重建有故障的连接，但它似乎非常脆弱......

现在进入 Web Api：看起来基于 HTTP 的堆栈可能更健壮（没有通道，没有端点，也可以在 Windows 服务中自托管）。通道中断似乎没有问题，因为每个请求都是单独处理的。因此，如果某些事情失败了，您只需重复请求即可。 （而且我们在其他应用程序中使用过 ASP.NET MVC，所以这对我们来说并不新鲜）。

现在我们正在考虑最好的选择。是“强化”我们现有的 WCF 服务（一个服务接口，大约 15 个操作）还是将接口移动到 Web Api 并作为 HTTP 请求（使用 JSON 数据）运行它更好？性能不是我们这里的主要问题...

有什么想法吗？ 哈特穆特

【参考方案1】：

我建议您坚持为您的 WPF 应用程序使用 WCF (SOAP) 服务，而不是迁移到 Web API。有许多的原因。首先，我认为我们需要考虑新的 Web API 试图解决的问题——即提供一个支持 RESTful/HTTP/超媒体服务的框架。这可能非常适合构建大量使用 HTTP 的应用程序，例如 Web、移动和 JavaScript 应用程序，在这些应用程序中，您希望最大化服务的“覆盖范围”或互操作性（无论平台如何）。这并不是说您不能将它用于 WPF 客户端，但在您的情况下，所有流量都在您的域中，因此坚持当前的实现更有意义。

您为服务/客户所做的绑定选择对我来说听起来不错。我将专注于您的渠道出现故障的原因并解决这些问题。您可能还想考虑通过 IIS 托管您的服务并使用 WAS 来公开您的非 HTTP 端点。过去我在这方面取得了很大的成功，而且大部分情况下都相当稳定。它还消除了管理您自己的主机的一些麻烦。如果您担心 TCP 绑定错误，那么只需创建一个新的 HTTP 或 wsHTTP 端点并使用它。这将为您提供与 Web api 使用的完全相同的传输，而无需更改您的编程模型。

【讨论】：

如果自托管 WebAPI 仍然是自托管 WCF 的更好选择，您是否介意更新我们。