设计一个数据库层DLL来支持插入替换

Question

我想知道是否有一种智能方式来设计一个C＃DLL，以便以后可以重新构建它并使用新版本作为“保险箱中的插入替换” “的态度。安全主要是指签名不会改变。

我正在考虑主要通过LINQ使用数据库与主要使用存储过程使用数据库之间的差异。存储过程的优点是，您可以更改任何单独的存储过程，而无需重新编译/重新发布应用程序。所以，我正在考虑如何通过创建一个解决方案来获得类似的能力，在这个解决方案中，所有面向数据库的代码都是在一个单独的项目中使用有趣的东西，比如dbml文件和什么。很明显，如果你在一个替换的LINQ函数的内部填充垃圾，替换会导致问题，但是这个缺点存在。

规则的主要排序，我想出了只是：

• 如果数据库模式的转变，是时候做一个重新编译。
• 防止任何签名更改。不应该删除现有的公共方法。

我的直觉是，这样做的很大一部分将涉及使用由单独项目引用并由主项目使用的接口来完成所有调用。

那么，这个想法是否有意义？是否有任何策略可以用来使这种安全（即不会重新编译存储过程而不重新编译应用程序）增加新的风险？

Answer 1

您描述的内容称为存储库，它们是域驱动设计的一部分。结合ORM（NHibernate，实体框架），这会给你一些灵活性。

但是，您仍然会遇到问题。当你在数据库中获得一个新的字段时，你的类结构将会改变，因为你得到了新的公共字段。

我不确定是否有可能将数据库层与代码库分离得如此完全，您可以简单地替换您的DLL，但上面可能是一个起点。

Answer 2

可以分离数据库层，以便您可以部署新的DLL。我们对我们的项目采取了类似的方法。

请注意，我们没有实现LINQ或任何其他ORM工具。相反，我们的DAL代码使用企业库提供的常规数据库访问。

关键是程序集有类和“提供者”负责加载和持久化类。当我们进行s'proc签名更改时，我们将更新适当的程序集。有时这需要向类定义添加额外的字段。

当我们添加这些字段时，我们会确定它们是否是必需的。如果是，那么这意味着必须修改主代码以支持这一点，并将整个部署在一起。如果没有，那么我们可以单独从主代码库中部署新的数据访问程序集。这就是说，对我们的对象模型的改变并没有以某种方式反映在主代码库中（例如新的输入字段），这是很难得的一天。对s'proc内部进行的更改经常发生，但是这些更改在SQL中完全处理，并且不需要更新DAL。