User Management Architecture Design

Transferred from:http://virusswb.blog.51cto.com/115214/1111442

Today, we share the following: User Management module

Or how the user management subsystem is designed, including how to abstract and related storage.

Most applications will have the concept of a user, unless your site is all anonymously accessed and does not save any information from the user. In fact, this is not good, because your site without the user's concept, no user module design, it is difficult to collect user information and user behavior, it is difficult to have data to analyze user preferences, but also less a way to provide better services to users.

Now is the era of web2.0, even web3.0, users are more and more concerned about the content of the site to bring themselves, the content of the display is appropriate for themselves, and users want to participate in the content of the site building, want to build their own content to aggregate, management.

Said so much, is to explain the user management module is very important, is an application should be considered, but also the top priority.

Let's take a look at what the user information contains.

Common content include: login account, login password, e-mail address, personal website, mobile phone, QQ, Introduction, label and so on.

Users may also include enterprise users, there will be: Enterprise name, Enterprise registration number, enterprise business number, business license number, legal person, contact person, contact title and so on enterprise information.

If it is an application involving money, for example: E-commerce website. There must be bank account information: The name of the bank, the name of the account, and the account number.

There are many types of users.

Some are individuals, some enterprises.

Some have bank account information, some do not have bank account information, there is no, it may be later.

User authentication may now be username/password and may require support for third-party certifications (for example, Weibo, TWITTER,QQ) and possibly SSO.

Single-user model, single-table storage model

The first thing to think about is a user model, and then put all the attributes on the model, and then add a user-type attribute to differentiate it. Different user types, using different attributes.

Create a table on the storage side, one field for each property. Although there are a lot of fields that can be wasted in some cases, even in the case of huge user volume, it is very wasteful. But the advantage is that from the model to the storage, are unique, the source is unique, save some to get Ah, type conversion and other trouble.

But there are other problems that require a lot of judgment in the code. What type, using those fields.

Multi-user model, multi-table storage model

The storage above is too wasteful and unclear, and all users are in a table and look a bit uncomfortable.

All right, let's split up. Depending on the user type, each user type is a model that stores a single table.

Individual users: Login account, login password, e-mail.

Enterprise User: Login account, login password, enterprise name, organization code, legal person.

This seems to be a little clearer, what kind of users need to use that user's model, go to that table to find.

But there are a few questions:

1. Landing is with Username/password, in two tables, it is written two times, but all the same AH. Well, there is a solution, that is to write a database view, in the view to connect two tables, query the view is OK. This also solves some need to query all users at the same time, good. However, as the user type increases, the database view needs to be maintained, otherwise the query results will produce errors. But when querying a single type of user, is it a direct use of the table? Or with a view? A little tangled up!

2. Need to increase bank account information, there are several types of users need to add, and some do not need to add. Well, open the tables and models you need to add, but with repetitive workloads, is it better?

！！！ In fact, I have a bit of sentiment, that is, your code and business closer to the more, its reusability will be lower, and some kind of business is bound, and even a business point of coupling. Of course, there are times when this is needed, and this code is for this business point to serve. But there are times when this is not the case. Let me give you an example. An entity has a lot of state, there are several states to decide whether or not to do something, you might write a method like this. Private Boo CanUpdate (status status) { if (status==status.wait| | Status==status.finish) {return true;} return false; } You may write a method Cando when the wait and finish status of the above also determines other actions. There are some repetitions of these two methods, which may be better if you define an intermediate state and reuse it. This example may also be inappropriate, or it may be a naming issue. This place also needs everybody to shoot the brick, the best is the clap, clap awake me, Pat understand me.

Information model, stored by information type

See the title, a lot of people must be confused, said the user how to do not mention the user's thing?

is actually abstract, the user is a kind of information.

After several years of expanding the user's information, think about it, list all the information, see how they built the model, how to design the storage, to better adapt to the development of the application.

From another angle, jump out of the application, out of business division, simply from the information properties to see if there is a solution.

I think it's possible to divide this.

• Verification Information: Login account, login password, e-mail.
• Basic information: Name, contact phone, mobile phone, location.
• Personal information: Document type, ID number.
• Enterprise Type information: Enterprise name, legal person, organization code, enterprise registration number.
• Bank account information: The name of the account, the location of the bank, the account name, the bank account number.

The types of business users in the application can be combined from these kinds of information, and can be added at any time to add a class of information. The underlying base model of user information is divided into several separate storage.

Business in a certain category of users, what information needs, from the user information in the underlying model to select those, combined into a business user model, the operation of the business.

Even the underlying underlying model can be used to mask the storage structure, storage, storage type of the business model.

There are several benefits to doing so:

1. 1. You can store all the user's verification information together, so it will be convenient to Username/password verification and add third-party verification.
2. 2. Eliminate blank fields and save storage space.
3. 3. Eliminate duplicate fields in a large number to prevent omissions.
4. 4. After several refactorings, it is possible to maximize the combination and separation of user business models. The upper business model is clear, the underlying model is clear, and the back-end storage model is clear.

User Management Architecture Design