Shulou(Shulou.com)06/02 Report--

This article mainly explains "what problems will be generated by the ID generated by the database". The content of the explanation in the article is simple and clear, and it is easy to learn and understand. Please follow the editor's train of thought to study and learn "what problems will be generated by the ID generated by the database"?

What is the problem of generating an application ID from a database?

First of all, the biggest problem is that you authorize an extremely important part of the application to third-party software, and when you delegate third-party responsibility, you have lost control of the application.

Second, you may use inappropriate methods when designing entity classes because you want it to be more compatible with a permanent framework, such as the entity framework in C# .NET. One of the most serious mistakes made by junior programmers is to use the public Id setter method to set ID.

Third, you suddenly have to rely on a third party to provide ID to the entity, which complicates otherwise uncomplicated unit tests. Suppose you've found that using public ID setter is essentially a serious error, and you don't want to set up ID by calling the code. The created class will look like this:

The ORM you choose can still set the id field through reflection. You know, with reflexes, nothing is really safe.

But how do you unit test this? Set the id field to 0 when instantiated. Instantiating multiple TerribleBook can lead to identity conflicts because more than one TerribleBook now has the same ID, even if they represent two different entities.

How can I generate a more appropriate ID and recover the license?

The method is actually very simple, take a look at the following code:

Not everyone can notice the transition from TerribleBook to FixedBook, so please read this code carefully.

First, ID changes from integers to strings, which makes it easier to scale, but be sure to limit the length of the fields in the database. Never use VARCHAR (MAX) on a field of known length-it takes up memory.

Then make the constructor private and instantiate the new object using the static factory method. This abstracts the instantiation logic from the caller and even gives us the opportunity to use polymorphism-- we might want to return a Null object instead of throwing it.

Note that although id is still taken as a constructor parameter, the generation and provision of ID is up to us (in line 18), not the database.

Guid.NewGuid (). ToString ("D") can only ensure that you get GUID in hyphen format. I like to use GUID, but you are free to build your own ID, no matter which kind of ID can meet your business and application needs.

Thank you for your reading, the above is the content of "what problems will be generated by the ID generated by the database". After the study of this article, I believe you have a deeper understanding of what problems will be generated by the ID generated by the database, and the specific use needs to be verified in practice. Here is, the editor will push for you more related knowledge points of the article, welcome to follow!

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.