您好,登錄后才能下訂單哦!
這篇文章主要介紹“基于Pydantic封裝的通用模型在API請求驗證中怎么應用”的相關知識,小編通過實際案例向大家展示操作過程,操作方法簡單快捷,實用性強,希望這篇“基于Pydantic封裝的通用模型在API請求驗證中怎么應用”文章能幫助大家解決問題。
首先,我們定義了以下幾個基礎的 Pydantic 模型:
DateModel
:用于表示日期范圍,包含開始日期和結束日期。
OrderModel
:用于表示排序參數,包含排序字段和排序方式(升序或降序)。
PageModel
:用于表示分頁參數,包含頁碼和每頁數量。
#!/usr/bin/python3 # -*- coding: utf-8 -*- # @author: hui # @Desc: { 通用的一些Pydantic模型 } # @Date: 2023/03/30 11:57 from pydantic import BaseModel, Field, validator from typing import Optional from datetime import date class DateModel(BaseModel): """日期模型""" start_date: Optional[date] = Field(None, description="開始日期") end_date: Optional[date] = Field(None, description="結束日期") @validator("end_date", always=True) def validate_end_date(cls, end_date, values): start_date = values.get("start_date") if all([start_date, end_date]) and end_date < start_date: raise ValueError("結束日期必須大于等于開始日期") return end_date class OrderModel(BaseModel): """排序模型""" order_by: Optional[str] = Field(None, description="排序字段,逗號分隔") order_mode: Optional[str] = Field(None, description="排序方式,逗號分隔,asc升序desc降序") @validator("order_by", "order_mode", always=True) def split_comma_separated_string(cls, value): if value: return value.split(",") return value @validator("order_mode", always=True) def check_length(cls, order_mode, values): order_by = values.get("order_by") if order_by and order_mode and len(order_by) != len(order_mode): raise ValueError("order_by and order_mode must have the same length") return order_mode class PageModel(BaseModel): """分頁模型""" page: Optional[int] = Field(default=1, ge=1, description="頁碼") page_size: Optional[int] = Field(default=10, le=1000, description="每頁數量, 默認10,最大1000")
接下來,我們通過混入(Mixin)和組合兩種不同的方式將這些基礎模型應用到一個實際的 API 請求中。
DateOrderModelMixin
類通過多重繼承的方式繼承了 DateModel
和 OrderModel
。這種方式的優點是簡單易懂,可以實現代碼重用。然而,它也可能導致類層次結構變得復雜,尤其是當有多個 Mixin 之間存在依賴關系時。
class DateOrderModelMixin(DateModel, OrderModel): """日期與排序模型Mixin""" pass
PageOrderModel
類通過組合的方式將 OrderModel
和 PageModel
作為它的屬性。在初始化方法中,我們將請求參數映射到這兩個模型,并調用基類的初始化方法。
組合模式的優點是代碼結構更清晰,易于維護和擴展。但是,它可能需要編寫更多的代碼來將功能委托給組合的組件。
class PageOrderModel(BaseModel): """分頁排序模型""" order_model: OrderModel = Field(OrderModel(), description="排序模型") page_model: PageModel = Field(PageModel(), description="分頁模型") def __init__(self, **data): if "order_model" in data and "page_model" in data: order_model = data.pop("order_model", None) page_model = data.pop("page_model", None) else: # 用于直接平鋪的字典入參 order_params = { "order_by": data.pop("order_by", None), "order_mode": data.pop("order_mode", None), } page_params = { "page": data.pop("page", None), "page_size": data.pop("page_size", None), } order_model = OrderModel(**order_params) page_model = PageModel(**page_params) super().__init__(order_model=order_model, page_model=page_model, **data) page_order = PageOrderModel( order_model=OrderModel(order_by="field1,field2", order_mode="asc,desc"), page_model=PageModel(page=1, page_size=10) ) >>>out order_model=OrderModel(order_by=['field1', 'field2'], order_mode=['asc', 'desc']) page_model=PageModel(page=1, page_size=10) req_params = { "order_by": "field1,field2", "order_mode": "asc,desc", "page": 1, "page_size": 10 } req_model = PageOrderModel(**req_params) >>>out order_model=OrderModel(order_by=['field1', 'field2'], order_mode=['asc', 'desc']) page_model=PageModel(page=1, page_size=10)
再來幾個業務邏輯模型繼承 DateOrderModelMixin 和 PageOrderModel 然后模擬一些請求參數去驗證
讓我們創建兩個業務邏輯模型,一個用于查詢商品信息,另一個用于查詢訂單信息。這兩個模型分別繼承 DateOrderModelMixin
和 PageOrderModel
。
from pydantic import BaseModel, Field from typing import Optional class ProductQueryModel(DateOrderModelMixin): product_category: Optional[str] = Field(None, description="商品類別") class OrderQueryModel(PageOrderModel): customer_id: Optional[int] = Field(None, description="客戶ID") # 使用 ProductQueryModel 進行參數驗證 product_query_params = { "start_date": "2023-04-01", "end_date": "2023-04-30", "order_by": "price", "order_mode": "desc", "product_category": "Electronics" } product_query = ProductQueryModel(**product_query_params) >>>out order_by=['price'] order_mode=['desc'] start_date=datetime.date(2023, 4, 1) end_date=datetime.date(2023, 4, 30) product_category='Electronics' # 使用 OrderQueryModel 進行參數驗證 order_query_params = { "start_date": "2023-04-01", "end_date": "2023-04-30", "order_by": "order_date", "order_mode": "asc", "page": 1, "page_size": 20, "customer_id": 12345 } order_query = OrderQueryModel(**order_query_params) >>>out order_model=OrderModel(order_by=['order_date'], order_mode=['asc']) page_model=PageModel(page=1, page_size=20) customer_id=12345
這里的 ProductQueryModel
和 OrderQueryModel
分別用于處理商品查詢和訂單查詢的請求參數。ProductQueryModel
繼承自 DateOrderModelMixin
,因此它具有日期范圍和排序功能。OrderQueryModel
則繼承自 PageOrderModel
,具有分頁和排序功能。
通過這兩個模型,我們可以輕松地驗證和解析傳入的請求參數。在上面的示例代碼中,我們分別創建了 product_query_params
和 order_query_params
字典來模擬請求參數,并使用 ProductQueryModel
和 OrderQueryModel
進行驗證。可以看到,這兩個模型成功解析了請求參數,并對日期范圍、排序和分頁進行了驗證。
在處理Pydantic模型時,根據具體的業務場景和需求來選擇組合或Mixin模式。
Mixin模式適用于簡單的繼承關系,代碼簡潔易懂;組合模式適用于復雜的類關系,提供更好的靈活性和擴展性。在實際項目中,可以根據需求靈活選擇這兩種模式,或者根據情況將它們結合使用。
在實踐中,如果需要將多個通用功能混合到一個業務邏輯模型中,Mixin模式可能是一個更好的選擇,因為它可以讓我們輕松地將這些功能組合在一起。然而,當我們需要對這些功能進行更精細的控制,或者在多個業務邏輯模型之間共享某些功能時,組合模式可能會更合適。
總之,在處理Pydantic模型時,我們應根據項目的實際需求和場景來權衡這兩種模式的優缺點,從而做出合適的選擇。這里的入參校驗感覺使用多繼承會更簡單點,但到一些復雜的業務邏輯處理時可以使用組合模式,來做到更好的維護與擴展。
由于 GET 請求的入參不太好定義數據結構,減少的代碼冗余就想到了多繼承來組合屬性和方法,如果使用 POST 請求傳遞 json 數據入參就可以更好設計參數結構,這時使用組合的方式hui更好。
go的結構體嵌套就有點像組合
type Address struct { Street string City string State string Zip string } type Person struct { Name string Age int Address Address }
通過結構體的組合,可以方便地組合多個不同的數據結構,構建出更加復雜的結構體。這種組合方式可以讓代碼更加靈活和可維護,同時也可以提高代碼的可讀性和可重用性。
關于“基于Pydantic封裝的通用模型在API請求驗證中怎么應用”的內容就介紹到這里了,感謝大家的閱讀。如果想了解更多行業相關的知識,可以關注億速云行業資訊頻道,小編每天都會為大家更新不同的知識點。
免責聲明:本站發布的內容(圖片、視頻和文字)以原創、轉載和分享為主,文章觀點不代表本網站立場,如果涉及侵權請聯系站長郵箱:is@yisu.com進行舉報,并提供相關證據,一經查實,將立刻刪除涉嫌侵權內容。