9

这是我之前关于F# Type Providers and Continuous Integration的问题的一个（实际上是几个）后续问题。

在我看来，使用SqlDataConnection类型提供程序作为编译时检查代码/数据库完整性在功能分支驱动的开发中保持不变是一个好主意；假设构建数据库也是 CI 过程的一部分，您会在每次提交/构建时知道没有对尚未应用于数据库的代码进行任何更改。

但是，出现了几个问题：

  1. 配置文件的名称（以及位置）在编译时与运行时不同，例如 app.config -> MyApp.exe.config，如果尝试使用会导致运行时错误

    SqlDataConnection<ConnectionStringName="DbConnection", ConfigFile="app.config">

    （实际上，ConfigFile="app.config"不需要指定，因为它是默认值。）

    通过将 app.config 文件复制到输出目录（有一个设置）可以避免运行时错误，但这会导致输出目录中同时存在 app.config 和 MyApp.exe.config 文件。不是很漂亮。为类型提供程序添加单独的配置文件将是另一种解决方案，但恕我直言，这也不是很漂亮。

    问题：有没有人想出一个更优雅的解决方案来解决这个问题？

  2. 当您来到构建服务器时，会出现下一个问题。您很可能不想在开发时针对相同的数据库进行编译，因此需要不同的连接字符串。是的，在生产中你还需要另一个。

    问题：您如何以最方便的方式解决这个问题？请记住，解决方案必须是 CI 流程的工作部分！

  3. 这种策略需要在构建服务器的每个构建上生成数据库，可能来自带有一些功能/冲刺更新脚本的基线脚本。

    问题：有没有人尝试过这个，它是如何影响构建时间的？如果是，您是如何创建此步骤的？

4

2 回答 2

2

在运行时，您可以使用GetDataContext接受连接字符串的重载。请参阅此处：向 Linq-To-Sql 数据提供程序提供连接字符串

于 2013-10-16T09:01:58.810 回答
0

我熟悉@Gustavo 提出的解决方案，但我一直觉得它有些可疑。关于必须指定两次连接字符串的事情……然而，当我再次得到相同的回复时，我慢慢开始意识到答案一定是正确的，而且是我想错了。这些是我的结论： 回复表明您可以使用接受连接字符串的 GetDataContext 重载。如果你把它改成should，事情就会变得更清楚，至少对我来说是这样。

问题是我一直认为类定义既是编译时指令又是运行时变量，但即使这是可能的，这也不是一个好主意。ConfigFile 参数的默认值是我们已经看到的“app.config”，但该文件在运行时不存在（具有该名称），因此尝试使用它没有意义，因此将 GetDataContext 作为唯一合理的选择。我建议你这样做：

  1. 将编译时设置保存在名为 compilation.config 的文件中（或任何您喜欢的文件），并指定此文件以在类定义中使用。

  2. 使用接受连接字符串的 GetDataContext 重载进行运行时解析，并在 app.config 文件中指定此连接字符串。

你最终会得到如下所示的东西：

type private dbSchema = SqlEntityConnection<ConnectionStringName="DbConnection", ConfigFile="compilation.config">
let private db = dbSchema.GetDataContext(ConfigurationManager.ConnectionStrings.["DbConnection"].ConnectionString)

哎呀，这甚至支持 SRP；一个文件中的编译时设置和另一个文件中的运行时设置！

关于我的其余问题，我假设答案在于持续部署管道中的一些脚本。不过，仍然对其他解决方案感兴趣。

于 2013-10-18T21:48:32.830 回答