Upper and lower floors

The current development architecture is generally a three-or four-tier architecture. The lower layer always provides interfaces or methods for upper-layer calls. In this case, a problem occurs: when the lower-layer interfaces or methods are called, how do I verify the correctness of input parameters? If the two layers belong to the same project or company project, you may also check the source code to see if the implementation method of the lower layer of the comment verifies the correctness of the parameter, but if we use other class libraries, what should we do when we cannot see the source code? Even in the same company and project, the writers of lower-layer interface methods do not know whether the parameter should be verified correctly in each method, whether it is not null (this is the most common ).

At this time, everyone should abide by a business agreement, and many problems can be solved. Here are two small examples:

Action

Service

Page listdata ()

In, Action calls a listdata method in the service that returns the page type, and then performs slight processing to display the data in the page. In this scenario, the page does not really care about whether there is data in the page. The action does not check (and is not necessary) whether there is data in the page, as long as the data in the page is not null (it must be clear that there is no difference between data and null), the page returned by the listdata interface of the service must not be null.

If the listdata method in is changed to the getuser method whose return type is mapuser, there is another saying. Most of the application scenarios of the getuser method require the identification of objects with real data. If the parameters passed by the action cannot be found in the service, the service must not return a mapuser object without any data, but return NULL. Let the action make its own judgment and then do what it should do.