Beginning Django E Commerce
398 pág.

Beginning Django E Commerce

DisciplinaProgramação I24.771 materiais281.850 seguidores
Pré-visualização50 páginas
data does not represent 3NF. While 
the category does describe the product, it\u2019s not really an attribute of the product. Logically, it makes 
sense to give categories their own table with their own primary key, and link them to products.
The correct pattern of normalization is highly subjective to your project\u2019s business requirements, 
and for some systems, can get complicated very quickly. It\u2019s one of the reasons that DBAs make the big 
bucks, and spend lots of time revising links between little boxes on company whiteboards. However, for 
our project, 3NF will solve most of the potential problems that might arise from poor database design. If 
you\u2019re interested in learning more about designing databases, I found Beginning Database Design, by 
Clare Churcher (Apress, 2007) to be a valuable resource. 
Even if you\u2019re still a little uncertain about exactly what we\u2019re going to do, don\u2019t fret. It always helps 
to put theory into practice, and that\u2019s what we\u2019re going to do when we create our models. 
What Django Gives You \u2013 The ORM 
As mentioned briefly in the first chapter, the Django framework is based loosely on the model-view-
controller (MVC) architectural style. This chapter is all about the \u201cM\u201d component of that acronym: 
model. In Django, models represent your data. You create a product model that has all the data you want 
to keep about your products, and then you start creating models, which are stored in your database. 
For those of you who\u2019ve worked with other web frameworks, such as ASP.NET or PHP, you might be 
familiar with n-tier architecture. This generally involves dividing your application into layers (usually 
three of them, referred to as three-tier) that all have a specific role to play. At the top, you have the 
Presentation Tier, which is your UI part of the web application that your user interacts with. At the 
bottom, you have the Data Tier that stores your information, typically in a relational database. Between 
both of these, you have the Business Tier (or Business Logic Layer), which facilitates communication 
between your Presentation and Data Tiers. Under n-tier architecture, when a customer requests a 
product page, the request is passed by the Presentation Tier down to the Business Tier, which turns 
around and makes its own request to the Data Tier. The response from the Data Tier is passed back up 
the chain to the Presentation Tier, which is then presented to the customer. 
This architecture is quite good, but if you\u2019ve ever set up a site this way, you know how much work it 
can be to set up initially. In your Data Tier, you need to create the database tables and any SQL stored 
procedures for manipulating your data, and in the Business Tier, you create classes in your server code 
(C# or PHP) that you populate with data and hand off to the Presentation Tier. After a while, you\u2019ll find 
yourself doing the same basic work for different objects, whether they\u2019re orders, products, or news 
In Django, a lot of this work is done for you, based on a few simple assumptions that tend to hold true: 
\u2022 One business tier class is mapped to one table in the database. 
\u2022 One business tier object instance is mapped to one record in the database table. 
\u2022 There are a limited number of things you can do to manipulate your data, based 
on the CRUD commands we covered earlier. 
First, one product object in your code tends to represent one record in the products table in your 
database. This isn\u2019t necessarily always true; for example, your product object could contain its category 
name, which might come from a different table. However, for our purposes in examining Django, it\u2019s 
safe to assume that one product object and its data can be mapped to one database record. From this, it 
makes sense to remove some of the repetition and do the work only in one place, and that\u2019s exactly what 
Django models do for you. 
Django models provide an object-relational mapping from your Python code to your database. That 
means that with only a few small exceptions, you\u2019ll only ever need to interact with your database via 
Python code. You can make a request for a Python object, and the Django ORM hands off the request to 
the relational database, gets the returned data, and then passes it on to you in the form of a Python 
object (hence the term \u201cobject-relational mapper\u201d). You don\u2019t need to write SQL to get at your data or 
call your database explicitly. As long as you have your database settings correctly configured in, you don\u2019t need to set this up from scratch.
In a lot of ways, the Django model layer is acting as both your Data Tier and your Business Tier. Of 
course, that isn\u2019t entirely accurate. You still have a MySQL database storing your information, and this 
has nothing to do with the Django model layer. However, the model layer does abstract away a lot of the 
work you would otherwise have to do with a web framework that didn\u2019t offer an ORM. 
Creating the Catalog App 
Before we jump into creating the models for our e-commerce project, a very quick note on Django apps. 
Typically, you\u2019ll divide your Django project up into different \u201capps.\u201d Each app contains view functions and 
a set of models that are all related to one particular type of functionality you need in your Django project. 
For example, it makes sense to create a Django app within your project to handle checkout 
functionality. This checkout app would contain models for order information and views for your site\u2019s 
checkout process, as well as any functionality that your checkout process requires in integrating with a 
payment processor (we\u2019ll get to that in Chapter 5 when we cover checkout). 
We\u2019re going to put our code and models for categories and their associated products into a Django 
app called catalog. To create the catalog app, open up your command line shell and, from the 
document root of your ecomstore project, enter the following: 
$ python startapp catalog 
This will create a directory within your project called catalog, which should contain four items:,,, and Let\u2019s quickly have a look at each one: 
\u2022 much like the one in the root of your project, this should be 
empty, and it\u2019s just there to let your system know that your catalog app 
contains Python code. 
\u2022 contains the classes mapped to your database tables, as well as any 
other information about your application data. 
\u2022 if you run automated tests for your code, the test runner will check this 
file for any test functions you have defined. We\u2019ll cover tests more in Chapter 14. 
\u2022 contains the view functions for your Django app. 
Another quick word about Django apps: the ability to partition different parts of your project into 
separate units is to facilitate the ease of code reuse. Much like your template directory, a Django app 
directory does not have to reside within the confines of your project directory. The djangodblog app 
that we added to our project in Chapter 2 is a perfect example of this. So, if you create a Django app that 
may be useful to you in more than one project, you are free to include it in any project you please. In our 
case, I find it more convenient to keep the catalog app, as well as the other apps I\u2019ll create in this book, 
inside the project directory, but as always, you are free to refactor anything I do to meet your own needs. 
With the catalog app in place, let\u2019s move along and do what you\u2019ve been itching to do since the 
beginning of the chapter: set up your product data. 
Creating the Django Models 
So now that your head is swimming around in all of this theory of system architecture, let\u2019s do 
something a little more