Part introduction Model The model is only related to data. It can generate, filter, save, verify data, and that's all.
As shown in the following example, when the message model calls the save method, it only receives JSON parameters and only returns an asynchronous task. In actual processing, it does not matter whether the result is synchronous or asynchronous. The reason for validation here is that it is an open object and is the last door to interaction with the server. In addition, it does not handle validation failures itself - it is selectively handled when called by the view, and a message may pop up or simply ignored and retried.
View A view is the visible part of the browser page. Each view object contains an associated jQuery object as a property (instance.$el ), similar to the DOM container in UI components. The
view also has two consistent methods: The
render method is used to get data from the model and render the data to the HTML page according to the defined template. The activate method is used to activate the view and bind related DOM events. All events are delegated to $el at most. In this example, CommentEditor is the parent view, ReplyList and ForwardList are two subviews displayed mutually, and the parent and subviews save references to each other.
Asynchronous task The literal translation of Deferred Object is delayed object, but It is more appropriate to understand it as an asynchronous task. Asynchronous tasks can eliminate multiple layers of nested callbacks, making code writing and reading more convenient.
From the above model and view code, it is obvious that after using asynchronous tasks, the code becomes more flat.
$.Deferred method creates a new two-way task queue: success callback function queue and failure callback function queue; the status of the task is also divided into two types: success and failure. You can use isResolved or isRejected to check the task respectively. The current status of the task, use resolve or reject to modify the task status.
The promise method returns a read-only copy of the task, and the task status cannot be modified on this copy. There is no doubt that models should always return only promise objects. (Note: The read-only copy can still call the promise method again to return the read-only copy)
In the Reply.create method, it can better handle custom asynchronous tasks instead of directly returning the native ajax asynchronous Task:
Purpose and Conclusion Why is it broken up like this?
Gains: Maintainability, clear API calls, elimination of if statements above the second level, elimination of callback statements above the second level, and each function controlled within twenty lines.
Result: There is no excessive duplication of code, all functions are packaged.
Statement:
The content of this article is voluntarily contributed by netizens, and the copyright belongs to the original author. This site does not assume corresponding legal responsibility. If you find any content suspected of plagiarism or infringement, please contact admin@php.cn