MVC的模型部分是内部平台吗？

Question

我并不是特别把MVC作为一个体系结构，但是这个模型不是仅仅是数据库的复制(除了慢一点和错误之外)吗？

既然现代数据库支持存储的查询、用户可定义的函数等等，那么为什么要把它们当作实现的细节呢？

是因为程序员通常不想学习SQL/ Relational吗？还是因为关系与对象模型之间存在根本的错配？

从广义上讲，数据库可以提供一个API，为什么要做两次&慢一点。

任何像McConnell这样的数字来备份视点将是非常感谢的。

Answer 1

你把事情搞错了。

该模型不是数据库的一个糟糕的副本。没有程序员关心数据库。数据库的存在只是为了在将来的调用中，我们可以轻松地重构业务对象的相同状态。数据库严格来说是达到目的的一种手段。它们允许进行一些处理，并提供了一些技巧来加速海量存储访问所造成的低效率，但它们也是造成这些低效率问题的唯一原因。如果我们能够完全没有数据库，而是将业务对象神奇地保存在驯服独角兽的记忆中，我们就会在心跳中完成它。

模型不是那样的。该模型支持我们可以用首选编程语言进行的所有操作，这就是我们选择它的原因。模型是我们想要编程的。它是这个系统的核心，所以它是非常重要的，不要用其他层次的关注来污染它。这就是为什么索引、表扫描等应该被排除在模型之外的原因，也是为什么组合框、HTTPRequests等应该被排除在外的原因。

没有模型意味着处理读取和写入小部件的相同代码也处理SQL插入和连接参数。这将是非常糟糕的，因为考虑两个完全不同的事情总是会使您作为开发人员的效率降低一半。这就是S为什么要将这些关注点分开，并有处理UI、业务逻辑和数据存储的层。这会导致代码数量的增加，但是由于每个生成的类都更明确地关注它应该做的事情，所以一般的效率都会提高。

这一结果在几代程序员身上很难获得，而且由于不明显，每一代新一代都必须再次相信，他们最好不要一次做任何事情。但是大多数专业人士都会确认，在这方面，拥有更多更简单的类更好，即使您最终总共拥有更多的代码行。

Answer 2

只有在最不复杂的应用程序中，模型才可能是数据库的复制，甚至不一定是复制的。

从根本上说，这假设在提交给使用者的数据与数据库的表结构(无论是关系型还是其他关系型)之间存在1到1的映射，而在现实中很少出现这种情况。

如果我们查看MVC -- Model是视图的模型--即使这只是表示单个表中的一行，也有可能会有查找，呈现给使用者的字段有一个值，但是存储在数据库中的字段有一个ID，您的模型很可能包含显示值以及持久化的实际数据。

然后，我们进入各种有趣的问题，有关验证-什么，如何和地点。

现在再走一步--注意，我说的是“消费者”--如果这个消费者不是看屏幕的最终用户，那么它是一个使用API的单一页面应用程序呢？在这一点上，从客户端面向应用程序的角度来看，没有数据库--但是有一个模型.

这给了我们一种逻辑分离，在这里我们看到了适合于上下文的模型--一种用于UI，另一种用于业务逻辑，然后是存储模型，它很可能是关系型的，涉及多个表。通过分别处理它们并确保我们能够轻松地在它们之间进行映射，我们最终在总体结构中获得了很大的灵活性(在这里，“系统”可能会很小地跨越多个应用程序)。

当然，如果您所做的一切都是对数据表的直接CRUD，那么数据模型和视图模型之间的关系可能非常密切，但是如果使用关系数据库，仍然会有一些映射。