【Django开发】前后端分离美多商城项目第2篇:项目准备【附代码文档】
  EiWeI2urgSTW 2024年03月15日 104 0

美多商城项目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仓库查看

感兴趣的小伙伴可以自取哦,欢迎大家点赞转发~

【版权声明】本文内容来自摩杜云社区用户原创、第三方投稿、转载,内容版权归原作者所有。本网站的目的在于传递更多信息,不拥有版权,亦不承担相应法律责任。如果您发现本社区中有涉嫌抄袭的内容,欢迎发送邮件进行举报,并提供相关证据,一经查实,本社区将立刻删除涉嫌侵权内容,举报邮箱: cloudbbs@moduyun.com

  1. 分享:
最后一次编辑于 2024年03月15日 0

暂无评论

推荐阅读
  FDKzLYdEIPfq   2024年01月20日   37   0   0 Erlang
  WlSdi7InVlWI   2024年01月20日   20   0   0 Erlang
  xAb1xM1k7m9X   2024年01月20日   17   0   0 Erlang
  9hb4VdMwrvXq   2024年01月20日   19   0   0 Erlang
EiWeI2urgSTW