C# 什么是数据库模型？

什么是“数据库模型”？这个类是否适合包含用于向数据库读写方法的方法？

在研究了一点MVC之后，我有信心地说，模型部分是我应该与数据库通信的地方。我目前有我的实体类（比如经典的“Person”）和一个名为DatabaseModel的类，该类具有用于在数据库上执行SQL查询的公共方法

然后，在控制器中的其他类中，我创建了一个DatabaseModel对象，并在该类中执行公共方法来检索SQL查询结果

---

我的方法正确吗？另外，我感觉这个DatabaseModel类将变得非常大。是否有一个很好的策略来分解这个问题（可能是针对相关的查询）。我曾想过在C#中将其划分为部分类，但这是我目前最好的猜测。

数据库模型是数据库模式的映射结构，在这种情况下，它将是实体类，所以回到定义；已经说过了。为了交互或查询您的数据库，您可以遵循两种常见模式，DAO模式，简单地说，这是一个类，包含每个实体的主要查询操作CRUD操作或[保存、更新和删除]，这意味着如果您具有PersonEntity，您应该具有PersonDAO

第二种模式是Repository模式，我认为您可以在任何强大的框架中使用该模式，并且可以使用现成的CRUD方法直接使用它，而无需为每个操作编写定义代码，这与DAO模式不同

---

说到每个类中的代码数量，实际上这取决于，但是你应该遵循干净的代码策略，也就是说，对于任何一个类来说，你不应该做任何事情来发现自己拥有超过400行的代码，举个例子。除非你真的需要这样做。

在研究了一点MVC之后，我有信心地说，模型部分是我应该与数据库通信的地方。目前，我有自己的实体类（如经典的“Person”）和一个名为DatabaseModel的类，该类具有在数据库上执行SQL查询的公共方法。

事实上我不同意，这是我开始时的误解。对我来说，M是到数据库的映射，它是数据库本身，使用实体框架或您选择的其他框架，因此您可以使用代码优先的方法创建数据库，而不必接触SQL

然后，在控制器的其他类中，我创建一个DatabaseModel对象，并在该类中执行公共方法以检索SQL查询结果。

这应该是存储库的一项工作，您可以在其中检索SQL查询结果，请记住，这不是实际的控制器

我是否正确地处理了这个问题？另外，我有一种感觉，这个DatabaseModel类将变得非常大。是否有一个很好的策略来分解这个问题（可能是针对相关的查询）。我曾想过用C#将它划分为部分类，但这是我目前最好的猜测。

您就快到了，您现在拥有的是模型（数据库映射），存储库（执行和检索数据的地方），但是您缺少控制器（在这里，您使用依赖项注入获取存储库并执行实际工作，例如将数据映射到您的ViewModel），您的ViewModel（如果您映射数据，以便只从数据中获取并发送所需的内容到视图，起初这似乎毫无意义，为什么我们不能只将数据发送到视图，但它有许多好处，例如，您只处理实际需要的内容，您可以验证用户输入（客户端验证）在将其映射回数据等之前），最后是视图（您的显示器）

---

所以对我来说，MVC只是一个标准，它并不意味着你只有模型视图和控制器，我从不喜欢缩写词，它一开始会引起太多的混淆，对我来说，它应该是：M（模型，数据库映射）C（控制器）VM（视图模型）V（视图），以及模型和控制器之间的存储库，但让我们忽略这一点，因为这是个人偏好的事情，大多数时候人们只是对模型和ViewModel之间的差异感到困惑。

因此，您的项目应该分为以下几类：实体类或模型、repoI如何处理模型、视图模型、控制器，然后再处理视图您认为这是DAO的一个好例子吗？幸运的是，它似乎与其他一些模式不同（MVVM目前正在扼杀我，不是在概念上而是在实际实现）。示例：另外，如果我创建多个具体的DAO（对于单独的模型对象和接口），创建一个封装所有这些具体DAO的类是否合适？这样我就不必创建多个DAO来访问不同模型对象的查询了？您完全正确，如果您遵循DAO模式，您当然需要封装它们来聚合您的需求。