A schema instance separating the front-end from the back end

To the front-end and back-end of the separation is very agreeable, this to the maintenance of the system is a considerable benefit. I also designed a system like this, so I took it out and discussed it with you. This architecture is not so much about trying to come out as the best practice that I have done systematically.

We do the system, the front-end pages are basically the use of JavaScript rich side of the page, the main application of the framework used, jquery, jquery UI, Knockout JS, Durandal, in addition, there are some of their own encapsulated UI components, the back end of the main technology has OData, MVC, LINQ to SQL, and one of the Rights management components you write yourself, the database uses SQL Server 2005.

Here to introduce the functions of each module and the purpose of its division, we first look at the user interface

First, about the front end of the Dataprovider

Simply put, is a call to the interface of the data access layer, a lot of people are such a question, add a data access layer here, is not redundant? As long as you do the front end, you will encounter the following questions:

1, a product or project, the front-end and the back end is at the same time, there is no backend interface, even can say, even the definition of an interface is not. As a front-end developer, how do you carry out your work?

2, as front-end developers, you have not encountered, because the back end of the interface hangs, causing your work can not continue to do the situation?

3, as a front-end developers, often unavoidable to and third party interface docking, you have not met, and you do docking personnel, suddenly because the project tight, was pumped away, leaving you only a bunch of need to pass n parameters, passed after the "object is empty" anomaly? You have no idea where the parameters are wrong. In the face of these interfaces, you don't get any help except for swearing.

4, as a front-end developers, you have not tried, you end of the development group, to an interface, they need to discuss a few days, and then spend a few days to give you, after you, still can not use, and to spend a few days to debug it?

If you have ever touched these problems, as I have, you will not doubt the existence of this dataprovider is necessary, with this dataprovider, you can minimize the impact of backend interface on front-end development. Here is an example of a dataprovider:

var Dataprovider = (function () {

var fakeprovider = {
countries:new countries ()
};

var realprovider = {
countries:new jdata.webdatasource ()
};

The following interface, according to the situation two select a return
fakeprovider;//This is a false dataprovider, read from the local return
realprovider;//This is true Dataprovider, from Interface Read
}) ();

As you can see from the above, the Dataprovider uses the factory pattern to create, it has two instances, Fakeprovider and Realprovider,fakeprovider are used to provide some analog data, and Realprovider provides data that is read from the interface. When there is no interface, or the interface hangs, we can read the data from the Fakeprovider first. The interface is OK, switch to Realprovider.

II. Validation of user interface input

1, the data verification. After the user enters the data in the interface, it then calls the interface in the Dataprovider to process the data, but before submitting it to the server, it has to validate the data first. How does that validation work? Dataprovider first obtain the description of the entity from the server, including but not limited to: the primary foreign key, the validation information of the attribute (such as whether it is nullable), and of course, the entity information can be cached for reuse. The Dataprovider then validates the data based on the descriptive information.

2, the error message display

When the validation to a certain attribute is not legitimate, the validation of the information module on the page to find the corresponding input control, it is how to find it? For example, it is not possible for contry Name input to be null. Then it looks for the element with ID coutry, and then coutry the element below to find the ID or name name, and if not, the Direct Bounce window displays an error message. For example:

<form id= "Country" >
       <input name= "name"/>
</form>

Third, on the back-end use of OData

1, as a backend developer, have you ever encountered such a front-end developer, today let you add a field, OK, add, and then package the release. I'll let you add a field tomorrow. The day after tomorrow suddenly said, the first two days add the field, do not need, you will have a kind of want to shout "" "Impulse?

2, as a back-end developer, have you ever encountered such front-end developers, today with you said that the interface is not enough, to add a Getuserbyname method, tomorrow and said, still have to add a Getuserbyemail method? Then, after a while, you find the interface more and more, maintenance of the module more and more carbuncle swollen, and these interfaces, you only dare to add, dare not delete. Because, you do not know these, there is no need, you run to ask the front end, he also can not answer. So some interfaces, even if they are useless, can only be in the system forever, until the end of its life cycle.

If you also encounter similar to my trouble, the use of OData may be a good choice, the permissions of the query are developed to the front-end developers, he loves how to check, all by it.

Iv. about back-end usage MVC

Our system, using MVC, is used to handle data submitted from the front end, using it primarily as a developer familiar with MVC, and then MVC calling business-layer code, as well as dealing with:

1, to submit the data to verify

2, processing system exceptions, including the return of the exception to the packaging, and then back to the client, so that the client processing. Record the information for the exception.

V. Data Access Layer

About the data access layer, in our system is actually an ORM wrapper (ORM Wrapper), you are wrapping a layer of ORM. The aim is to:

1, the data interception. For example: Some data, only the development of a role. The data access layer needs to regenerate the SQL based on the filter criteria and then combined with the query criteria.

2, the processing of data false deletion. See a lot of systems, are removed to the business layer to carry out, in fact, this is not appropriate, from the business point of view, care is to delete, after the implementation of the deletion, this data from my eyes disappear on it. To the true deletion or the false deletion, this has nothing to do with me. Data access layer, to do is this work, it can be the data in the real deletion and false deletion between the switch, as long as the configuration, you can turn the real deletion into a fake delete (in fact, the delete operation into the update operation), so that the business developers, no longer care about the true and false deletion of data.

3, the data tracking, backup. You must have had such a need to write down, the time of each update operation, and what was updated. For the 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 functionality provided by the data, not within the scope of the discussion.