用数据库生成的ID会生成什么问题

这篇文章主要讲解了"用数据库生成的ID会生成什么问题"，文中的讲解内容简单清晰，易于学习与理解，下面请大家跟着小编的思路慢慢深入，一起来研究和学习"用数据库生成的ID会生成什么问题"吧！

用数据库生成应用ID会造成什么问题?

首先，最大的问题是你把应用程序中一个极其重要的部分授权给第三方软件，在授权第三方责任时，你已经失去了对这个应用程序的掌控权。

其次，在设计实体类时，你可能会使用不恰当的方法，因为你想让它与一个永久框架更兼容，比如说C# .NET中的实体框架。初级程序员犯的最严重的一个错误就是使用public Id setter方法来设置ID。

第三，你突然要依靠第三方来给实体提供ID，这会把原本不复杂的单元测试变得复杂。假设你已经发现使用public ID setter本质上是一个严重的错误，而你又不想通过调用代码来设置ID。创建的类看起来会如下所示：

你选择的ORM仍然可以通过反射来设置id字段。要知道，有反射存在就没有什么是真正安全的。

但该如何对此进行单元测试?实例化时将id字段设置为0。实例化多个TerribleBook会出现身份冲突情况，因为现在不止一个TerribleBook具有相同的ID，即便他们代表两个不同的实体。

如何生成更合适的ID并追回授权?

方法其实非常简单，看下面的代码：

不是人人都能注意到TerribleBook到FixedBook之间的转变，所以请认真阅读这段代码。

首先，ID由整数变成字符串，这样可以更好地实现伸缩性，但一定要限制数据库中字段的长度。永远不要对已知长度的字段使用 VARCHAR(MAX)——它会占用内存。

然后将构造函数设为私有，并使用静态工厂方法实例化新对象。这样可以从调用者中抽象出实例化逻辑，甚至为我们提供了使用多态的机会——我们可能想返回某个Null对象而不是抛出。

注意，虽仍然把id当作构造函数参数，但是ID的生成和提供是由我们来决定的(在第18行)，而不是数据库。

Guid.NewGuid()。ToString("D")只能确保获得连字符格式的GUID。笔者喜欢用GUID，但是你可以自由构建自己的ID，无论哪种ID都可以满足你的业务和应用程序需求。

感谢各位的阅读，以上就是"用数据库生成的ID会生成什么问题"的内容了，经过本文的学习后，相信大家对用数据库生成的ID会生成什么问题这一问题有了更深刻的体会，具体使用情况还需要大家实践验证。这里是，小编将为大家推送更多相关知识点的文章，欢迎关注！