我想知道是否有一种智能的方法来设计C＃dll，以便您以后可以重建它并以“安全”的方式使用新版本作为替代品。安全主要是指签名不会改变。
我正在考虑主要通过LINQ使用数据库与主要使用存储过程使用数据库之间的区别。存储过程的优点是您可以更改任何单个存储过程，而无需重新编译/重新发布应用程序。所以，我正在考虑通过创建一个解决方案来获得类似能力需要什么，其中所有面向数据库的代码都在一个单独的项目中，使用有趣的东西，如dbml文件和诸如此类的东西。显然，如果你在一个替换LINQ函数的内部填充垃圾，替换将导致问题，但存在这种缺点。
我想出的主要规则是：
我的直觉是，执行此操作的很大一部分将涉及使用由单独项目引用并由主项目使用的接口以进行所有调用。
那么，这个想法有意义吗？是否有任何策略应该用于使其合理安全（即，除了在不重建应用程序的情况下编辑存储过程之外，不会增加太多新风险）？
答案 0 :(得分：0)
您所描述的内容称为存储库，它们是域驱动设计的一部分。结合ORM（NHibernate，实体框架），这将为您提供一些灵活性。
但是，你仍然会遇到问题。当您在数据库中获得新字段时，您的类结构将会更改，因为您将获得新的公共字段。
我不确定是否有可能将数据库层与您的代码库分开，所以完全可以简单地替换您的DLL，但上面可能是到达那里的起点。
答案 1 :(得分：0)
可以分离db层，以便您可以部署新的DLL。我们对我们的项目采取了类似的方法。
请注意，我们没有实现LINQ或任何其他ORM工具。相反，我们的DAL代码使用Enterprise Library提供的常规数据库访问。
关键是程序集有两个类和“提供者”负责加载和持久化类。当我们更改s'proc签名时，我们将更新相应的程序集。有时，这需要在类定义中添加其他字段。
在我们添加这些字段时，我们会确定是否需要它们。如果它们是，那么这意味着必须修改主代码以支持它并且整个部署在一起。如果没有，那么我们可以直接从主代码库部署新的数据访问程序集。
也就是说，对于我们的对象模型的更改并不是以某种方式（例如，新的输入字段）反映在主代码库中。对s'proc内部的更改经常发生，但这些更改在SQL中完全处理，并且不需要更新DAL。