问题标签 [vendor-neutrality]

当我编写应用程序时，我使用 System.Data 接口（IDbConnection、IDbCommand、IDataReader、IDbDataParameter 等...）。我这样做是为了减少对供应商的依赖。除非，我正在做一个简单的测试应用程序，否则在咨询时这似乎是合乎道德的事情。

但是，我看到的所有代码似乎都使用 System.Data.SqlClient 命名空间类或其他供应商特定类。在杂志和书籍中，很容易将其归结为 Microsoft 的影响力和他们的营销策略，只针对 SQLServer 进行编程。但它看起来就像我看到的几乎所有 .NET 代码都使用 SQLServer 特定类。

我意识到供应商特定的类具有更多功能，例如向 SqlCommand 对象添加参数是一种方法，而将其添加到 IDbCommand 是令人讨厌的 4 多行代码。但话又说回来; 为这些限制编写一个小助手类非常简单。

我还想知道当 SQLServer 是当前目标客户端时针对接口进行编程是否过度设计，因为它不是立即需要的。但我不认为这是因为针对接口进行编程的成本如此之低，因为减少供应商依赖性提供了如此巨大的好处。

您是否使用供应商特定的数据类或接口？

编辑：总结下面的一些答案，并提出我在阅读它们时的一些想法。

使用接口实现供应商中立性的可能陷阱：

• 嵌入在您的 SELECT 语句中的供应商特定关键字（我所有的 ins、upd 和 del 都在 procs 中，所以这不是问题）
• 直接绑定数据库可能会导致问题。
• 除非您的连接实例化是集中式的，否则无论如何都需要调用供应商特定的类。

使用接口的积极原因：

• 根据我的经验，客户一直很欣赏转移到不同供应商的能力（即使没有行使）。
• 在可重用代码库中使用接口

我们需要我们正在构建的应用程序与数据库无关。特别是，我需要它能够与 SQL Server、Oracle 和 MySQL 一起工作。将来，可能还会将其他数据库供应商添加到列表中。当然，要使用的任何数据库都将具有相同的模式。

为了构建一个原型来演示接口，我们将模式加载到 SQL Server DB 中，然后为该数据库生成 DataSet 和 TableAdapter。由于数据集是由数据库的特定实例生成的，我怀疑生成的 DataSet 和 TableAdapter 不是独立于供应商的。此外，我什至不确定它们是否可以用于另一个 SQL Server 数据库实例。

我的问题是：有没有办法将相同的自动生成的 DataSet 和 TableAdapter 与不同的数据库（可能还有供应商）一起使用？

干杯，

马科斯

我有一个 C# Windows Forms 应用程序，它的原型是在 SQL Server（强类型数据集）上创建的。在其最终版本中，该应用程序必须能够在 SQL Server、MySQL 或 Oracle 上运行。

现在我想知道可以从原型中重用哪些部分（如果有的话）。1. 数据集（类型化） ? 2. 表适配器？（可能不是，它们包含特定于 SQL Server 的语法） 3. 绑定到 DataGridViews

最重要的是，如果我们需要重新实现这一切，有没有办法在设计时做到这一点？或者，1. 我们是否需要以编程方式创建无类型数据集？2. 我们是否需要以编程方式创建它的数据适配器（或表适配器）？如果是，两者中的哪一个？3. 我们是否需要以编程方式创建其与界面的datagridviews 的绑定？

也许无关紧要：如果我们从现有的数据库模式创建一个实体模型（AFAIK 它提供数据库独立性），我们可以使用它以某种方式创建与我们的数据网格视图的绑定吗？

谢谢！

那么，为了保留我们的 Bindings 和 dataGridViews，以及我们已经实现的一些额外的逻辑，我们是不是应该把所有生成的 TableAdapter 都扔掉，手动编写呢？如果我们真的扔掉它们，我们应该使用 DataAdapters 来代替吗？

这是一种“按部就班”的方法吗？有没有人做过这样的事情？

更一般地说，如果您需要创建一个表单应用程序以在多个数据库中工作，您会这样做吗： A. 使用非类型化数据集、数据适配器/表格适配器和手动创建的绑定 B. 以某种方式生成独立于供应商的数据集和数据适配器/表格适配器（怎么样？）并在设计时通过VS gui C绑定它们。其他方式？？？

更新：

那么，为了保留我们的 Bindings 和 dataGridViews，以及我们已经实现的一些额外的逻辑，我们是不是应该把所有生成的 TableAdapter 都扔掉，手动编写呢？如果我们真的扔掉它们，我们应该使用 DataAdapters 来代替吗？

这是一种“按部就班”的方法吗？有没有人做过这样的事情？

更一般地说，如果您需要创建一个表单应用程序以在多个数据库中工作，您会这样做吗： A. 使用非类型化数据集、数据适配器/表格适配器和手动创建的绑定 B. 以某种方式生成独立于供应商的数据集和数据适配器/表格适配器（怎么样？）并在设计时通过VS gui C绑定它们。其他方式？？？

我目前正在开发一个 Web 应用程序项目，该项目可能安装在具有各种软件配置的多个不同服务器上。我希望通过允许用户安装各种 SQL 服务器来使我的应用程序尽可能灵活。问题是任何两个服务器供应商使用的 SQL 语法都不匹配。举个简单的例子，下面是 MS SQL 和 MySQL 的相同 SELECT 语句：

微软 SQL -SELECT TOP 1 * FROM MyTable ORDER BY DateCreated DESC

mysql -SELECT * FROM MyTable ORDER BY DateCreated DESC LIMIT 1

是否有任何标准方法可以为各种供应商抽象语句创建？任何在线资源或书籍讨论这个问题？有什么我觉得有用的提示或 smart-alec 评论吗？

更多信息：我正在用在 Windows 服务器上运行的 vanilla ASP 编写我们的应用程序。

谢谢，斯帕拉

我们使用的是 Visual Studio 2010，但这是最初使用 VS2003 构思的。

我会将最好的建议转发给我的团队。目前的设置几乎让我呕吐。这是一个 C# 解决方案，大多数项目都包含 .sql 文件。因为我们支持 Microsoft、Oracle 和 Sybase，所以自制了一个预处理器，很像 C 预处理器，只是替换是由自制的 C# 程序执行的，而不使用yacc类似的工具。#ifdefs用于条件宏定义，是的 - 宏就是这样做的方式。一个宏可以扩展为另一个或两个宏，但这最终应该终止。它们中只有宏#ifdef——其余的类似 SQL 的代码只使用这些宏。

现在，各种配置：Debug, MNDebug, MNRelease, Release, SQL_APPLY_ALL, SQL_APPLY_MSFT, SQL_APPLY_ORACLE, SQL_APPLY_SYBASE, SQL_BUILD_OUTPUT_ALL, SQL_COMPILE，以及另外 2 个。

还有：Any CPU, Mixed Platforms, Win32。

让我抓狂的是必须正确配置它以及从配置中选择正确的12 x 3 = 36配置，以及必须根据数据库类型替换数据库名称：配置、主数据库或网关。我认为应该将配置简化为仅 Debug、Release 和 SQL_APPLY。此外，使用 0、1 和 2 似乎是 80 年代......最后，我认为我打算为 3 种类型的供应商构建或不构建 3 种类型的数据库应该只配置一个井字游戏板，例如：

在这种情况下，这意味着构建 MSFT+CONFIG、所有 SYBASE 和所有 GATEWAY。

尽管如此，使用文本文件和预处理器以及许多配置的整体东西似乎非常笨重。现在是 2010 年，肯定会有人拥有非常干净和/或有创意的工具/解决方案。唯一的优点是现有的宏集合已经过很好的测试。

您是否曾经编写过适用于多个供应商的 SQL？你是怎么做到的？

SqlVars.txt（30 个用户中的每个人都制作了一个模板的副本并对其进行修改以满足他们的需要）：

是否有一个 SASS 扩展可以采用 SASS 样式表、查找中性属性（例如border-radius）并自动为其输出所有供应商特定的属性（例如-webkit-border-radius等）？

我真的不想手动创建所有的 mixin，也不想手动编写代码。我确定肯定有这样的扩展名，但我找不到。帮助？

目前我有一个涉及两个数据库提供者的项目：

1. SqlClient
2. 数据库

我需要创建一个处理这些提供程序的 DAL。我正在考虑创建一个这样的界面：

并单独实现（虽然很简单这是错误的方式）

我读过一些这样的帖子：

.Net：如何创建与供应商无关的数据集、表格适配器、绑定（DB 在运行时决定）（很好，但没有提供任何示例）

获取 DbProviderFactory

创建数据访问层 (C#)（非常好，但表适配器取决于供应商）

我想创建一个具有以下功能的 DAL：

1. 使用类型化数据表（使用 Visual Studio Designer）
2. 使用独立于供应商的数据适配器（手动创建）
3. 不是 ORM

如何创建具有这些功能的简单 DAL？

是否可以使用 Python NDB API 创建独立于 AppEngine 的应用程序？我需要在 AE 上使用数据库托管一些基本脚本，但我不想将供应商锁定到服务中。

我们正在尝试做一个 Microprofile 应用程序。由于 Microprofile 规范仍在蓬勃发展，许多供应商正在涌现。Helidon、OpenLiberty、Kumuliz、WildFly 等等。似乎这些供应商中的每一个都试图通过扩展、内部依赖项和配置模式来创建自己的利基市场（从而形成长期锁定）。

现在，为了避免供应商锁定，我们希望构建仅依赖于标准包的代码并避免任何特定于 impl 的 API 如果我们被迫使用供应商特定的 API，我们并不反对构建适配器或外墙或不同的图案。

这里有一些问题：

1. 我们的想法甚至可能吗？在构建时，我们可以选择通过配置文件包含特定实现的依赖项和配置。

2. 我们选择从 Helidon 和 Quarkus 开始。它们似乎都仅限于 Microprofile 功能，并且不包含像 JMS、EJB 等那样的 JEE fat。我们想对了吗？能有更好的选择吗？

3. 我们是否应该以不同的方式开始/在一个实现上达到我们的应用程序开发阶段，然后对其进行逆向工程以适应第二个供应商？（这确实节省了应用程序的上市时间）。

4. 这里有没有人研究过任何供应商的各个部分的中立性，对于 Microprofile 规范的每个部分？

有人已经走上了这条路吗？

请讨论你的想法..

我想使用 Ubuntu 用 C 语言开发一个基于 OpenCL 的应用程序。

但是开发包让我不知所措：

我可以只选择 nvidia opencl-dev，还是需要不同的包？我将在 nVidia 上进行调试，但我希望它也能在 AMD 上运行。