PYTHON framework-DJANGO Study Notes (9)

PYTHON framework-DJANGO Study Notes (9)
Previously, the basic way to build a website with Django was to create a view and URLConf. As we have explained, a view is responsible for processing some subjective logic and then returning response results. As an example, our subjective logic is to calculate the current date and time. In contemporary Web development, subjective logic often involves interaction with databases. The database driver Web site connects to the database server in the background, extracts some data from it, and then displays the data in beautiful format on the Web page. This website may also provide visitors with methods to modify Database Data. Many complex websites provide some combination of the above two features. For example, Amazon.com is a good example of a database-driven site. Essentially, each product page displays data in the database in HTML format. When you post a customer comment, the comment is inserted into the comment database. Due to the inherent Python simple and powerful database query execution method, Django is very suitable for developing database-driven websites. Before studying more code, let's take a moment to consider the overall design of Django data-driven Web applications. As mentioned above, Django's design encourages loose coupling and strict segmentation of different parts of the application. To follow this idea, it is easier to modify a part of the application without affecting other parts. In view functions, we have discussed the importance of separating the business logic from the presentation logic through the template system. At the database layer, we also applied the same idea to the data access logic. The concept of combining data access logic, business logic, and presentation logic is sometimes called the Model-View-Controller (MVC) mode of the software architecture. In this mode, the Model represents the data access layer, and the View represents what and how to display in the system, controller refers to the part of the system that accesses the model based on user input and as needed to determine which view to use. Django closely follows this MVC pattern, which can be called an MVC framework. The following are the meanings of M, V, and C in Django: M, data access part, which is processed by the django database layer. This chapter describes the content. V. The view and template process the data to be displayed and the data to be displayed. C. According to the user input, the Django Framework calls the appropriate Python function for the given URL Based on the URLconf settings. Since C is handled by the framework itself, Django focuses more on models, templates, and Views. Django is also called the MTV framework. In the MTV development Model, M represents the Model, that is, the data access layer. This layer processes all data-related transactions: how to access, how to Verify validity, What behaviors are included, and the relationship between data. T indicates the Template, that is, the presentation layer. This layer processes performance-related decisions: how to display them on pages or other types of documents. V represents the View, that is, the business logic layer. This layer contains the access model and related logic for obtaining the appropriate template. You can think of it as a bridge between a model and a template. If you are familiar with other MVC Web development frameworks, such as Ruby on Rails, you may think that the Django view is a controller, while the Django template is a view. Unfortunately, this is a misunderstanding caused by different interpretations of MVC. In Django's interpretation of MVC, views are used to describe the data to be presented to users. They are not how data is presented, but what data is presented. In contrast, Ruby on Rails and some similar frameworks advocate that controllers are responsible for deciding what data to present to users, while views only determine how to present data, rather than what data to present. None of the two interpretations are more correct. It is important to understand the underlying concepts. The stupid way to query databases in a view is just as the stupid way to output HTML in the view described in the previous section (by hardcoding the text in the view ), there is also a stupid way to get data from the database in the view. Simple: Execute an SQL query using any existing Python class library and process the results. In this example, we use the MySQLdb class library (available from the http://www.djangoproject.com/r/python-mysql/) to connect to the MySQL database, retrieve some records, and provide them to the template to display a web page: copy code 1 from django. shortcuts import render_to_response 2 import MySQLdb 3 4 def book_list (request): 5 db = MySQLdb. connect (user = 'root', db = 'data', passwd = '123456t', host = 'localhost') 6 cursor = db. cursor () 7 cursor.exe cute ('select name FROM books order by name') 8 names = [row [0] Row in cursor. fetchall ()] 9 db. close () 10 return render_to_response('book_list.html ', {'names': names}) This method is available for copying code, but soon some problems will appear in front of you: we encode the database connection parameters in the code. Ideally, these parameters should be stored in the Django configuration. We have to repeat the same code: Create a database connection, create a database cursor, execute a statement, and then close the database. Ideally, all we need is to specify the desired results. It hangs us down on MySQL. If we want to switch from MySQL to SQLServer after a period of time, we have to use different database adapters, change the connection parameters, and modify the SQL according to the type of SQL statement. Ideally, the database server used should be abstracted, so that the database server can be changed with only one modification. (This feature is appropriate if you are building an open-source Django application to be used by as many people as possible .) As you expected, the Django database layer is dedicated to solving these problems. The following shows in advance how to use the Django database API to override the previous view. 1 from django. shortcuts import render_to_response2 from mysite. books. models import Book3 4 def book_list (request): 5 books = Book. objects. order_by ('name') 6 return render_to_response('book_list.html ', {'books': books}) Now I only have a general understanding of it. I will further understand this code.