我开始使用 MVC 框架的最大障碍与 1 模型到 1 数据库表的概念有关。对我来说，除了简单的应用程序之外，任何东西都过于简单和不切实际。然而，MVC 无处不在，包括这个很棒的 StackOverflow 站点。通常，我遇到的所有代码示例和教程都非常简单，并且在这些情况下一对一的关系可以正常工作。但是，我正在寻找的是地址表连接的 MVC 模型的真实世界示例。在 stackoverflow 的情况下，我会想象一个带有问题、标签、用户等表的数据库设计。在我的数据库设计中，我可能有一个 Question_Tag 链接表来查找与给定问题关联的所有标签。 MVC 如何处理这个问题？
【问题讨论】：
标签： model-view-controller database-design
我不相信the MVC design pattern 有任何说明每个域类应该有一个数据库表。事实上，MVC 设计模式中没有任何内容表明您的模型应该或必须保存在关系数据库中。
这只是一些流行的框架（Ruby on Rails - 也可能是 ASP.NET MVC？）采取的策略，似乎是为了方便。但这不是 MVC 的要求。 Spring MVC（用于 Java 世界）没有关于如何将模型组件映射到数据库的固有概念，事实上它的美妙之处在于它不关心 - 您只需要提供要使用的模型数据，以及您从哪里获得它来自 MVC 框架并不关心。
因此，换句话说，您不需要假设 MVC 模式意味着您必须为每个模型组件使用一个数据库表。哎呀，您甚至不需要使用数据库，您的模型也可以来自平面文件或 Web 服务（MVC 的优点在于，如果您正确设计应用程序，您可以交换不同的数据层实现和退出您的应用程序，视图或控制器甚至不知道）。
【讨论】：
我认为您将 MVC 与 ORM 混淆了。 ORMS 将您与数据库表和对象一对一绑定。
您需要做的是将模型对象从 MVC 发送到 DAL 层，该层可以从 SQL 查询中为您填充它们并返回对象。同样，您可以将具有更改的填充对象发送回 DAL 层以进行持久化。
这是一种更简洁灵活的设计，您可以将其与 MVC 模式一起使用，并且您不必将对象耦合到数据库表，同时使用 SQL 的连接功能。
【讨论】：
好的，艾哈迈德，这是有道理的。但是在我见过的所有 MVC 示例中，该模型是某种组合的 BLL/DAL。您所说的是将模型保持为纯 BLL 并创建单独的 DAL。我认为使用现有 mvc 框架的主要功能之一是加快开发速度。如果我必须在 MVC 之上创建 DAL，我不妨坚持我现有的非 MVC 开发流程，即创建具有单独业务逻辑和数据访问层的页面。
【讨论】：