From 342ae636ac51223acc57e9bcac905d607cb19358 Mon Sep 17 00:00:00 2001
From: Gao Lei <7885834+ladiesman218@users.noreply.github.com>
Date: Sun, 11 Feb 2024 01:03:06 +0800
Subject: [PATCH] There were 2 'use', changed first one to 'should' (#967)

---
 docs/fluent/model.md | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/docs/fluent/model.md b/docs/fluent/model.md
index 76f128ee..1845fc45 100644
--- a/docs/fluent/model.md
+++ b/docs/fluent/model.md
@@ -366,7 +366,7 @@ When serializing to / from `Codable`, model properties will use their variable n
 
 Model's default `Codable` conformance can make simple usage and prototyping easier. However, it exposes the underlying database information to the API. This is usually not desirable from both a security standpoint - returning sensitive fields such as a user's password hash is a bad idea - and a usability point of view. It makes it difficult to change the database schema without breaking the API, accept or return data in a different format, or to add or remove fields from the API.
 
-For most cases you use use a DTO, or data transfer object instead of a model (this is also known as a domain transfer object). A DTO is a separate `Codable` type representing the data structure you would like to encode or decode. These decouple your API from your database schema and allow you to make changes to your models without breaking your app's public API, have different versions and make your API nicer to use for your clients.
+For most cases you shoud use a DTO, or data transfer object instead of a model (this is also known as a domain transfer object). A DTO is a separate `Codable` type representing the data structure you would like to encode or decode. These decouple your API from your database schema and allow you to make changes to your models without breaking your app's public API, have different versions and make your API nicer to use for your clients.
 
 Assume the following `User` model in the upcoming examples.