【Django開發】前後端分離美多商城專案第2篇:專案準備【附程式碼文件】

程序员一诺yinuo發表於2024-03-15

美多商城專案4.0文件完整教程(附程式碼資料)主要內容講述:美多商城,專案準備,商業模式介紹,開發流程,需求分析,專案架構,建立工程,1. 在git平臺建立工程1.B2B--企業對企業,2.C2C--個人對個人,3.B2C--企業對個人,4.C2B--個人對企業,5.O2O--線上到線下,6.F2C--工廠到個人,7.B2B2C--企業--企業--個人,1. 使用者部分,2. 商品部分,3. 購物車部分,4. 訂單部分,5. 支付部分,2. 新增前端檔案,3. 建立Django REST framework工程,4. 修改manage.py,5. 建立資料庫。專案準備,配置,使用者部分,使用者模型類,註冊1. 修改settings/dev.py 檔案中的路徑資訊,2. INSTALLED_APPS,3. 資料庫,4. Redis,5. 本地化語言與時區,6. 日誌,7. 異常處理,設計介面的思路。使用者部分,圖片驗證碼,簡訊驗證碼,跨域CORS。使用者部分,使用Celery完成傳送簡訊,判斷帳號是否存在,註冊1. 判斷使用者名稱是否存在,2. 判斷手機號是否存在:。使用者部分,JWT,什麼是JWT,Django REST framework JWT起源,基於token的鑑權機制,JWT長什麼樣?,JWT的構成,總結,安裝配置,使用。使用者部分,登入,登入,返回登入網址的檢視建立模型類,urllib使用說明。登入,登入回撥處理建立模型類,urllib使用說明。登入,繫結使用者身份介面,使用者中心個人資訊,郵件與驗證,使用Django傳送郵件建立模型類,urllib使用說明。郵件與驗證,儲存郵箱併傳送驗證郵件,驗證郵箱連結,收貨地址。收貨地址,省市區地址查詢。收貨地址,使用快取,使用者地址管理,使用者地址管理程式碼,商品部分。商品部分,資料庫表設計,FastDFS分散式檔案系統,Docker使用表結構,資料庫模型類,1. 什麼是FastDFS,2. 檔案上傳流程,3. 簡易FastDFS構建。Docker使用,Docker簡介1. 虛擬化,2. 什麼是Docer,3. Docker元件,4 使用Docker做什麼。Docker使用,安裝與操作,使用Docker安裝FastDFS1. 在Ubuntu中安裝Docker,2. 啟動與停止,3. Docker映象操作,4. Docker 容器操作,5. 將容器儲存為映象,6. 映象備份與遷移,1. 獲取映象,2. 執行tracker,3. 執行storage。商品部分,FastDFS客戶端與自定義檔案儲存系統,CKEditor富文字編輯器,新增測試資料1. FastDFS的Python客戶端,2. 自定義Django檔案儲存系統,3. 在Django配置中設定自定義檔案儲存類,4. 新增image域名。商品部分,頁面靜態化,定時任務,靜態化首頁的手動指令碼。商品部分,商品詳情頁。商品部分,使用者瀏覽歷史記錄1. 儲存,2. 檢視。商品部分,商品列表頁獲取商品列表資料。商品部分,商品搜尋。購物車部分,購物車資料儲存設計,新增到購物車1. Redis儲存已登入使用者,2. Cookie儲存未登入使用者。購物車部分,查詢購物車資料,修改購物車資料,刪除購物車資料,購物車全選。購物車部分,登入合併購物車,訂單部分,訂單資料庫設計,訂單結算。訂單部分,儲存訂單,下單成功頁面。支付,接入,發起支付,儲存支付結果。Xadmin,使用者許可權控制,資料庫讀寫分離1. 安裝,2. 使用。資料庫讀寫分離,MySQL主從同步,配置Django實現資料庫讀寫分離,部署1. 主從同步的定義,2. 主從同步的機制,3. 配置主從同步的基本步驟,4. 詳細配置主從同步的方法。。meiduo_mallBuild Setup。

全套筆記資料程式碼移步: 前往gitee倉庫檢視

感興趣的小夥伴可以自取哦,歡迎大家點贊轉發~


專案準備

配置

1. 修改settings/dev.py 檔案中的路徑資訊

我們將Django的應用放到了 工程目錄/meiduo_mall/apps目錄下,如果建立一個應用,比如users,那麼在配置檔案的INSTALLED_APPS中註冊應用應該如下:

INSTALLED_APPS = [
    ...
    'meiduo_mall.apps.users.apps.UsersConfig',
]

為了還能像如下方式簡便的註冊引用,我們需要向Python直譯器的導包路徑中新增apps應用目錄的路徑。

INSTALLED_APPS = [
    ...
    'users.apps.UsersConfig',
]

我們將配置檔案改為放在settings子目錄下,所以 配置檔案中的BASE_DIR指向的變為了meiduo/meiduo_mall/meiduo_mall

使用sys.path新增<BASE_DIR>/apps目錄,即可新增apps應用的導包路徑。

  
  
# Build paths inside the project like this: os.path.join(BASE_DIR, ...)
  
  
BASE_DIR = os.path.dirname(os.path.dirname(os.path.abspath(__file__)))

  
  
# 新增導包路徑
  
  
import sys
sys.path.insert(0, os.path.join(BASE_DIR, 'apps'))

2. INSTALLED_APPS

在INSTALLED_APPS中新增rest_framework

INSTALLED_APPS = [
    ...
    'rest_framework',
]

3. 資料庫

DATABASES = {
    'default': {
        'ENGINE': 'django.db.backends.mysql',
        'HOST': '127.0.0.1',  # 資料庫主機
        'PORT': 3306,  # 資料庫埠
        'USER': 'meiduo',  # 資料庫使用者名稱
        'PASSWORD': 'meiduo',  # 資料庫使用者密碼
        'NAME': 'meiduo_mall'  # 資料庫名字
    }
}

注意:

記得在meiduo/meiduo_mall/__init__.py檔案中新增

import pymysql

pymysql.install_as_MySQLdb()

4. Redis

安裝django-redis,並配置

CACHES = {
    "default": {
        "BACKEND": "django_redis.cache.RedisCache",
        "LOCATION": "redis://10.211.55.5:6379/0",
        "OPTIONS": {
            "CLIENT_CLASS": "django_redis.client.DefaultClient",
        }
    },
    "session": {
        "BACKEND": "django_redis.cache.RedisCache",
        "LOCATION": "redis://10.211.55.5:6379/1",
        "OPTIONS": {
            "CLIENT_CLASS": "django_redis.client.DefaultClient",
        }
    }
}
SESSION_ENGINE = "django.contrib.sessions.backends.cache"
SESSION_CACHE_ALIAS = "session"

除了名為default的redis配置外,還補充了名為session的redis配置,分別使用兩個不同的redis庫。

同時修改了Django的Session機制使用redis儲存,且使用名為'session'的redis配置。

此處修改Django的Session機制儲存主要是為了給Admin站點使用。

**關於django-redis 的使用,說明文件可見[

5. 本地化語言與時區

LANGUAGE_CODE = 'zh-hans'

TIME_ZONE = 'Asia/Shanghai'

6. 日誌

LOGGING = {
    'version': 1,
    'disable_existing_loggers': False,  # 是否禁用已經存在的日誌器
    'formatters': {  # 日誌資訊顯示的格式
        'verbose': {
            'format': '%(levelname)s %(asctime)s %(module)s %(lineno)d %(message)s'
        },
        'simple': {
            'format': '%(levelname)s %(module)s %(lineno)d %(message)s'
        },
    },
    'filters': {  # 對日誌進行過濾
        'require_debug_true': {  # django在debug模式下才輸出日誌
            '()': 'django.utils.log.RequireDebugTrue',
        },
    },
    'handlers': {  # 日誌處理方法
        'console': {  # 向終端中輸出日誌
            'level': 'DEBUG',
            'filters': ['require_debug_true'],
            'class': 'logging.StreamHandler',
            'formatter': 'simple'
        },
        'file': {  # 向檔案中輸出日誌
            'level': 'INFO',
            'class': 'logging.handlers.RotatingFileHandler',
            'filename': os.path.join(os.path.dirname(BASE_DIR), "logs/meiduo.log"),  # 日誌檔案的位置
            'maxBytes': 300 * 1024 * 1024,
            'backupCount': 10,
            'formatter': 'verbose'
        },
    },
    'loggers': {  # 日誌器
        'django': {  # 定義了一個名為django的日誌器
            'handlers': ['console', 'file'],  # 可以同時向終端與檔案中輸出日誌
            'propagate': True,  # 是否繼續傳遞日誌資訊
            'level': 'DEBUG',  # 日誌器接收的最低日誌級別
        },
    }
}

7. 異常處理

修改Django REST framework的預設異常處理方法,補充處理資料庫異常和Redis異常。

新建utils/exceptions.py

from rest_framework.views import exception_handler as drf_exception_handler
import logging
from django.db import DatabaseError
from redis.exceptions import RedisError
from rest_framework.response import Response
from rest_framework import status

  
  
# 獲取在配置檔案中定義的logger,用來記錄日誌
  
  
logger = logging.getLogger('django')

def exception_handler(exc, context):
    """
    自定義異常處理
    :param exc: 異常
    :param context: 丟擲異常的上下文
    :return: Response響應物件
    """
    # 呼叫drf框架原生的異常處理方法
    response = drf_exception_handler(exc, context)

    if response is None:
        view = context['view']
        if isinstance(exc, DatabaseError) or isinstance(exc, RedisError):
            # 資料庫異常
            logger.error('[%s] %s' % (view, exc))
            response = Response({'message': '伺服器內部錯誤'}, status=status.HTTP_507_INSUFFICIENT_STORAGE)

    return response

配置檔案中新增

REST_FRAMEWORK = {
    # 異常處理
    'EXCEPTION_HANDLER': 'meiduo_mall.utils.exceptions.exception_handler',
}

使用者部分

使用者模型類

Django提供了認證系統,文件資料可參考此連結[

Django認證系統同時處理認證和授權。簡單地講,認證驗證一個使用者是否它們聲稱的那個人,授權決定一個透過了認證的使用者被允許做什麼。 這裡的詞語“認證”同時指代這兩項任務,即Django的認證系統同時提供了認證機制和許可權機制。

Django的認證系統包含:

  • 使用者
  • 許可權:二元(是/否)標誌指示一個使用者是否可以做一個特定的任務。
  • 組:對多個使用者運用標籤和許可權的一種通用的方式。
  • 一個可配置的密碼雜湊系統
  • 使用者登入或內容顯示的表單和檢視
  • 一個可插拔的後臺系統

Django預設提供的認證系統中,使用者的認證機制依賴Session機制,我們在本專案中將引入JWT認證機制,將使用者的身份憑據存放在Token中,然後對接Django的認證系統,幫助我們來實現:

  • 使用者的資料模型
  • 使用者密碼的加密與驗證
  • 使用者的許可權系統

Django使用者模型類

Django認證系統中提供了使用者模型類User儲存使用者的資料,預設的User包含以下常見的基本欄位:

  • username

必選。 150個字元以內。 使用者名稱可能包含字母數字,_@+ .-個字元。在Django更改1.10:max_length從30個字元增加到150個字元。

  • first_name

可選(blank=True)。 少於等於30個字元。

  • last_name

可選(blank=True)。 少於等於30個字元。

  • email

可選(blank=True)。 郵箱地址。

  • password

必選。 密碼的雜湊及後設資料。 (Django 不儲存原始密碼)。 原始密碼可以無限長而且可以包含任意字元。

  • groups

Group 之間的多對多關係。

  • user_permissions

Permission 之間的多對多關係。

  • is_staff

布林值。 指示使用者是否可以訪問Admin 站點。

  • is_active

布林值。 指示使用者的賬號是否啟用。 我們建議您將此標誌設定為False而不是刪除帳戶;這樣,如果您的應用程式對使用者有任何外來鍵,則外來鍵不會中斷。它不是用來控制使用者是否能夠登入。 在Django更改1.10:在舊版本中,預設is_active為False不能進行登入。

  • is_superuser

布林值。 指定這個使用者擁有所有的許可權而不需要給他們分配明確的許可權。

  • last_login

使用者最後一次登入的時間。

  • date_joined

賬戶建立的時間。 當賬號建立時,預設設定為當前的date/time。

常用方法:
  • set_password(raw_password)

設定使用者的密碼為給定的原始字串,並負責密碼的。 不會儲存User 物件。當Noneraw_password 時,密碼將設定為一個不可用的密碼。

  • check_password(raw_password)

如果給定的raw_password是使用者的真實密碼,則返回True,可以在校驗使用者密碼時使用。

管理器方法:

管理器方法即可以透過User.objects. 進行呼叫的方法。

  • create_user(username, email=None, password=None, ***extra_fields*)

建立、儲存並返回一個User物件。

  • create_superuser(username, email, password, ***extra_fields*)

create_user() 相同,但是設定is_staffis_superuserTrue

建立自定義的使用者模型類

Django認證系統中提供的使用者模型類及方法很方便,我們可以使用這個模型類,但是欄位有些無法滿足專案需求,如本專案中需要儲存使用者的手機號,需要給模型類新增額外的欄位。

Django提供了django.contrib.auth.models.AbstractUser使用者抽象模型類允許我們繼承,擴充套件欄位來使用Django認證系統的使用者模型類。

我們現在在meiduo/meiduo_mall/apps中建立Django應用users,並在配置檔案中註冊users應用。

在建立好的應用models.py中定義使用者的使用者模型類。

class User(AbstractUser):
    """使用者模型類"""
    mobile = models.CharField(max_length=11, unique=True, verbose_name='手機號')

    class Meta:
        db_table = 'tb_users'
        verbose_name = '使用者'
        verbose_name_plural = verbose_name

我們自定義的使用者模型類還不能直接被Django的認證系統所識別,需要在配置檔案中告知Django認證系統使用我們自定義的模型類。

在配置檔案中進行設定

AUTH_USER_MODEL = 'users.User'

AUTH_USER_MODEL 引數的設定以點.來分隔,表示應用名.模型類名

注意:Django建議我們對於AUTH_USER_MODEL引數的設定一定要在第一次資料庫遷移之前就設定好,否則後續使用可能出現未知錯誤。

執行資料庫遷移

python manage.py makemigrations
python manage.py migrate

註冊

建立好使用者模型類後,我們開始來實現第一個業務邏輯——使用者註冊。

設計介面的思路

  • 分析要實現的業務邏輯,明確在這個業務中需要涉及到幾個相關子業務,將每個子業務當做一個介面來設計。

  • 分析介面的功能任務,明確介面的訪問方式與返回資料:

    • 介面的請求方式,如GET 、POST 、PUT等
    • 介面的URL路徑定義
    • 需要前端傳遞的資料及資料格式(如路徑引數、查詢字串、請求體表單、JSON等)
    • 返回給前端的資料及資料格式

在前後端分離的應用模式中,我們作為後端開發人員設計後端介面時,可以不用考慮返回給前端資料後,前端如何處理,這是前端開發人員的工作,我們只需明確我們要儲存的或者要返回的是什麼資料即可。

明確上述每一點後,即可開始編寫介面。

註冊業務介面分析

在使用者註冊中,需要實現以下介面:

  • 圖片驗證碼
  • 簡訊驗證碼
  • 使用者名稱判斷是否存在
  • 手機號判斷是否存在
  • 註冊儲存使用者資料

圖片驗證碼、簡訊驗證碼考慮到後續可能會在其他業務中也用到,因此我們將圖片驗證碼獨立,建立一個新應用verifications,在此應用中實現圖片驗證碼、簡訊驗證碼

未完待續, 同學們請等待下一期

全套筆記資料程式碼移步: 前往gitee倉庫檢視

感興趣的小夥伴可以自取哦,歡迎大家點贊轉發~

相關文章