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

This article focuses on "web front-end and back-end separation of architecture case analysis", interested friends may wish to take a look. The method introduced in this paper is simple, fast and practical. Next let the editor to take you to learn "web front-end and back-end separation of the architecture case analysis" it!

First, about the dataProvider of the front end

To put it simply, it is a data access layer for calling the interface. Many people wonder whether it is superfluous to add a data access layer here. As long as you do the front end, you will encounter the following problems:

1. For a product or project, the front-end and back-end are carried out at the same time. At this time, there is no back-end interface at all, or even a definition of an interface. As a front-end developer, how do you do your own work?

2. As a front-end developer, have you ever encountered a situation where you can't continue your work because the back-end interface is down?

3. As a front-end developer, it is often inevitable to dock with the interface of a third party. Have you ever met a person who docked with you suddenly because the project was tight and was taken away, leaving you with only a bunch of N parameters to pass? after passing it, what about the exception of "object is empty"? You have no idea where the parameters are wrong. In the face of these interfaces, you can get no help but to curse.

4. As a front-end developer, have you ever tried to ask the back-end development team for an interface? they need to discuss it for a few days, and then it will take a few more days to give it to you. After giving it to you, it will not work, and how many more days will it take to debug it?

If you, like me, have encountered these problems before, you will not doubt the necessity of this dataProvider. With this dataProvider, you can reduce the impact of back-end interfaces on front-end development. Here is an example of dataProvider:

Var dataProvider = (function () {var fakeProvider = {countries: new Countries ()}; var realProvider = {countries: new JData.WebDataSource ()}; / / the following interface, according to the situation, choose one of the two return fakeProvider; / / this is a fake dataProvider, read return realProvider; / / this is the real dataProvider locally, read from the interface}) ()

As you can see from the above, this dataProvider is created using the factory pattern, and it has two instances, fakeProvider and realProvider,fakeProvider are used to provide some simulation data, and realProvider provides data read from the interface. When there is no interface, or when the interface is down, we can read the data from fakeProvider first. When the interface is ready, switch to realProvider.

II. Verification of user interface input

1. Data verification. After entering the data in the interface, the user then calls the interface in dataProvider to process the data, but the data has to be verified before it is submitted to the server. Well, how is this verification carried out? DataProvider first obtains entity description information from the server, including but not limited to: primary foreign key, attribute verification information (such as nullability), of course, this entity information can be cached for reuse. DataProvider then validates the data against this description.

2. Display of error messages

When verifying that a property is illegal, the module that validates the information looks for the corresponding input control on the page. How does it find it? For example, it is not possible to have an empty Name input for Contry. Then it first looks for the element whose id is Coutry, and then under the Coutry element looks for the control with id or name as Name. If it cannot find it, it will display an error message directly. For example:

Third, about the use of OData at the back end

1. As a back-end developer, have you ever come across this kind of front-end developer? today you are asked to add a field, OK, add it, and then package and release it. I'll ask you to add another field tomorrow. The day after tomorrow suddenly said, the field added two days ago, do not need, will you have the impulse to shout "fuck"?

2. As a back-end developer, have you ever come across this kind of front-end developer who told you today that the interface is not enough and that you need to add a GetUserByName method, and tomorrow, you have to add a GetUserByEmail method? Then, after a period of time, you find that there are more and more interfaces, the maintenance modules are becoming more and more swollen, and you only dare to add these interfaces, but do not dare to delete them. Because, you do not know these, which do not need, you run to ask the front end, he can not answer. So even if some interfaces are useless, they can only be in the system forever until the end of its life cycle.

If you have similar troubles like mine, it may be a good choice to use OData to develop all the permissions of the query to the front-end developer, who can check whatever he likes and let it go.

Fourth, about the use of MVC at the back end

In our system, MVC is used to process the data submitted from the front end, mainly because developers are familiar with MVC, and then MVC calls the business layer code, at the same time, it also needs to deal with:

1. Verify the submitted data

2. Handle the exception of the system, including repackaging the exception and sending it back to the client to facilitate the handling of the client. Record the abnormal information.

5. Data access layer

With regard to the data access layer, in our system it is actually an ORM Wrapper of ORM, and you wrap a coat around the ORM. The purpose is to:

1. Intercept the data. For example: some data, only for the development of a role. The data access layer needs to regenerate the SQL according to the filter conditions and then combined with the query conditions.

2. The processing of false deletion of data. I have seen many systems where deletion is carried out on the business layer, but this is not suitable. From a business point of view, I am concerned about deletion. After performing the deletion, this piece of data will disappear from my eyes. Whether it is true or false, it has nothing to do with me. This is what the data access layer needs to do. It can switch data between true deletion and false deletion. As long as you configure it, you can change the true deletion into a false deletion (in fact, turn the Delete operation into a Update operation), so that business developers no longer have to care about the true or false deletion of data.

3. Track and back up the data. You must have encountered a need to write down the time of each update operation and what has been updated. For deleted data, you can restore it back. The data access layer, by wrapping the ORM, can record every update, delete these operations, and then record them. Of course, these requirements can also be implemented using the functions provided by the data, and are not within the scope of discussion.

At this point, I believe that everyone on the "web front-end and back-end separation of architecture instance analysis" have a deeper understanding, might as well to the actual operation of it! Here is the website, more related content can enter the relevant channels to inquire, follow us, continue to learn!

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.