不要再使用数据库生成的ID。许多人至少有过一次使用数据库为应用程序生成ID的经历。但实际上，这种做法在开发应用程序的过程中是一个很大的错误，使用自增整数ID会更加错误。是时候一劳永逸地摆脱这种不良行为了。当然，这将与您在101大学平台关系数据课程中学到的内容以及无数关于如何使用TerribleIds()创建表的youtube视频形成鲜明对比。使用数据库生成appID有什么问题？首先，最大的问题是您将应用程序的一个极其重要的部分授权给第3方软件，并且在委托第3方责任时，您已经失去了对应用程序的控制权。其次，您在设计实体类时可能会使用不适当的方法，因为您希望它与持久性框架更加兼容，例如C#.NET中的实体框架。初级程序员犯的最严重的错误之一是使用公共Idsetter方法来设置ID。第三，您突然不得不依赖第三方来为实体提供ID，这使原本不复杂的单元测试变得复杂。假设您已经发现使用公共ID设置器本质上是一个严重的错误，并且您不想调用代码来设置ID。创建的类将如下所示：您选择的ORM仍然可以通过反射设置id字段。要知道，只要反思存在，就没有什么是真正安全的。但是你如何对它进行单元测试呢？实例化时将id字段设置为0。实例化多个TerribleBooks会产生身份冲突情况，因为现在不止一个TerribleBook具有相同的ID，即使它们代表两个不同的实体。如何生成更合适的ID并恢复授权？方法其实很简单，看下面的代码：TerribleBook和FixedBook之间的转换不是每个人都能注意到的，所以请仔细阅读这段代码。首先，将ID从整型改为字符串，可以更好的实现可扩展性，但是必须限制数据库中字段的长度。切勿在已知长度的字段上使用VARCHAR(MAX)-它会消耗内存。然后将构造函数设为私有并使用静态工厂方法来实例化新对象。这从调用者那里抽象了实例化逻辑，甚至给了我们使用多态性的机会——我们可能想要返回一些Null对象而不是抛出。请注意，虽然id仍然用作构造函数参数，但ID的生成和提供是由我们决定的（第18行），而不是由数据库决定。引导。新指南（）。ToString("D")仅确保您获得带连字符的GUID。笔者喜欢使用GUID，但您可以自由构建自己的ID，只要满足您的业务和应用需求即可。现在，我们已经收回了控制权。图片来源：unsplash你可能会说：“但实体将不再按顺序存储！”这是完全正确的，但无需担心。初级开发人员喜欢以有序的方式存储实体，即使它通常对业务没有影响。如果您确实需要按顺序存储内容，只需创建一个日期时间列即可。
