本教程详细介绍在laravel多语言应用中，如何通过重写模型（model）的`newquery()`方法，实现数据查询时自动根据当前应用语言环境进行过滤。这种方法提供了一种优雅且dry（don’t repeat yourself）的解决方案，避免了在每次数据查询时手动添加语言条件，确保了所有通过该模型进行的查询都能自动包含语言过滤逻辑，从而简化多语言数据管理。
引言：多语言应用的查询挑战
在构建多语言网站时，通常会在数据库的每个相关数据表中添加一个 language 字段，用于区分不同语言版本的数据。例如，一个产品表可能包含英文、中文等不同语言的产品描述。当用户访问网站时，系统需要根据当前的语言环境（例如 app::getLocale()）来检索对应语言的数据。
然而，在laravel中，这意味着每次从模型查询数据时，我们都可能需要手动添加一个 where(‘language’, App::getLocale()) 条件。这种重复性的操作不仅繁琐，而且容易遗漏，导致代码冗余且难以维护。虽然Laravel的“全局作用域”（Global Scopes）可以解决这个问题，但对于那些几乎总是需要语言过滤的模型，可能存在一种更底层、更直接的实现方式，即重写模型的 newQuery() 方法。
理解 newQuery() 方法
newQuery() 方法是Laravel Eloquent模型的核心组成部分之一。它负责在每次需要创建一个新的查询构建器实例时被调用。无论你是使用 Model::all()、Model::find(1)、Model::where(‘column’, ‘value’) 还是 Model::query()->…，最终都会通过 newQuery() 方法来获取一个基础的查询构建器。
通过重写这个方法，我们可以在查询构建器被返回给调用者之前，注入我们自定义的默认查询条件。这意味着任何从该模型发起的查询，都将自动包含我们预设的条件，从而实现全局性的行为修改。
实现自动语言过滤
要为特定的模型实现自动的语言过滤，只需在该模型类中重写 newQuery() 方法，并在其中添加语言过滤条件。
假设我们有一个 Product 模型，并且其对应的数据表包含一个 language 字段。我们希望所有对 Product 模型的查询都自动过滤出当前语言的产品。
示例代码：
<?php namespace AppModels; use IlluminateDatabaseEloquentBuilder; use IlluminateDatabaseEloquentModel; use IlluminateSupportFacadesApp; // 引入 App Facade class Product extends Model { /** * Get a new query builder for the model's table. * * @return IlluminateDatabaseEloquentBuilder */ public function newQuery(): Builder { // 调用父类的 newQuery() 方法获取原始查询构建器 return parent::newQuery()->where('language', App::getLocale()); } // ... 模型的其他属性和方法 ... }代码解释：
- parent::newQuery(): 这是关键一步。我们首先调用父类 Model 的 newQuery() 方法，以获取一个未经修改的、基础的查询构建器实例。这是为了确保我们不会破坏Eloquent模型原有的查询初始化逻辑。
- ->where(‘language’, App::getLocale()): 在获取到基础查询构建器之后，我们链式调用 where() 方法，添加语言过滤条件。
- ‘language’：这是你数据库表中用于存储语言信息的字段名。
- App::getLocale()：这是一个Laravel辅助函数，用于获取当前应用的语言环境。它会返回一个字符串，例如 ‘en’、’zh’ 等。
工作原理与优势
一旦你在模型中重写了 newQuery() 方法，所有通过该模型进行的查询都将自动包含 where(‘language’, App::getLocale()) 条件。
例如：
// 这将只返回当前语言的产品 $products = Product::all(); // 这也将只返回当前语言中 ID 为 1 的产品 $product = Product::find(1); // 这会返回当前语言中 category_id 为 5 的所有产品 $categoryProducts = Product::where('category_id', 5)->get();这种方法的优势在于：
- DRY (Don’t Repeat Yourself): 无需在每次查询时手动添加语言条件，减少了重复代码。
- 集中管理: 语言过滤逻辑被集中封装在模型内部，易于维护和修改。
- 透明性: 对于调用者而言，查询代码保持简洁，无需关心底层的语言过滤细节。
- 底层实现: 作为模型创建查询的入口，这种方式非常基础和可靠。
注意事项与高级用法
尽管重写 newQuery() 方法非常强大，但也有一些需要考虑的场景和潜在问题：
-
绕过自动过滤： 如果某些情况下，你需要查询所有语言的数据（例如，在后台管理界面），而不想应用语言过滤，那么直接重写 newQuery() 会带来不便。此时，你可以考虑以下几种策略：
- 使用全局作用域的 withoutGlobalScopes(): 如果你将语言过滤实现为全局作用域，可以使用 Product::withoutGlobalScopes()->get() 来绕过。
- 自定义方法： 在模型中添加一个自定义方法来获取未过滤的查询构建器：
public function newQueryWithoutLanguageFilter(): Builder { return parent::newQuery(); } // 使用：Product::newQueryWithoutLanguageFilter()->get(); - 条件判断： 在 newQuery() 内部添加条件判断，例如基于某个配置或请求参数来决定是否添加语言过滤。但这会使 newQuery() 变得复杂。
-
性能影响： 对于简单的 WHERE 条件，通常对数据库查询性能影响甚微。数据库索引（如果 language 字段有索引）会进一步优化查询速度。
-
适用场景： 此方法最适用于那些绝大多数情况下都需要进行语言过滤的模型。如果一个模型在很多场景下都需要在有语言过滤和无语言过滤之间切换，那么全局作用域（Global Scopes）可能提供更大的灵活性，因为它们可以更容易地被启用或禁用。
-
与全局作用域的比较：
- newQuery() 重写： 更底层，直接修改了查询构建器的初始化过程。一旦设置，所有通过该模型创建的查询都受影响。
- 全局作用域： 也是一种自动应用查询条件的方式，但它更像是一个“插件”，可以更容易地被移除（withoutGlobalScopes()）。它通常被认为是更“Laravel惯用”的方式来处理这类问题。
- 选择哪种方式取决于个人偏好和具体需求。对于本教程中的“始终过滤”场景，newQuery() 提供了一个简洁直接的解决方案。
总结
通过重写Laravel Eloquent模型的 newQuery() 方法，我们可以优雅地实现多语言数据查询的自动过滤。这种方法将语言过滤逻辑内聚到模型本身，大大简化了应用层代码，提高了可维护性和开发效率。在处理多语言数据时，理解并运用这种机制，能够帮助开发者构建更健壮、更专业的Laravel应用程序。在实际应用中，请根据具体需求权衡其与全局作用域的优劣，选择最适合项目的实现方案。
以上就是Laravel模型中实现多语言数据自动过滤：重写newQuery()方法的详细内容，更多请关注php中文网其它相关文章！