当围绕模型-视图-控制器(MVC)设计应用程序时，工具箱中有什么？

Question

对于设计模式有很多很好的解释，但是我很难找到很好的资源来展示如何在实践中使用它。

所以，当你启动一个新的应用程序(不管它是什么)，你的工具箱里有什么？

例如，有人建议，在围绕MVC设计应用程序时，使用UMLCollabative图( http://www.objectmentor.com/resources/articles/umlCollaborationDiagrams.pdf )可能是有用的，尽管我不确定这种情况究竟是如何发生的，也不清楚为什么会如此……？

那么，您的MVC工具箱中有什么呢？

Answer 1

图表对于帮助可视化数据流非常有用。数据是几乎每一个程序的基础。做得好的UML向您展示了数据存储的位置(模型)、正在查看数据的内容(控制器)以及如何显示数据(视图)。

MVC系统的一个具体例子可能是博客应用程序。诸如博客条目、评论之类的数据可以存储到数据库中。这是模型部分。视图部分将是为页面构造html的一组例程。这些不是完整的，它们只是一个框架，所以如果它们没有输入就运行，它们会产生一些静态的可视元素和一些空框。他们负责内容的审美呈现。

控制器将通过从数据库请求数据，并将其交给html例程显示，以及通过html页面接受用户的输入，并提出进一步的数据显示请求，将两者结合在一起。

这个范例的一个重要方面是视图框架和数据库提供的接口可以是通用的。如果获取文章的方法总是getArticle(ArticleID)，那么后端是如何实现的并不重要，无论是SQL数据库、散列数据库还是一组平面文件。所需要做的就是交出原始的文章数据。

同样，视图软件只需要能够处理原始数据。这是CSS之所以重要的原因之一，而标记的思想也很重要。如果您的文章数据只有语义标记，如段落、分隔等，并且避免命名字体或颜色或其他美学属性，那么您可以为一个完全不同处理美学的视图使用相同的接口。例如，它可以把它渲染成盲文，或者说它。

我希望这会有所帮助，而不仅仅是你所读到的其他解释的又一次概括。

Answer 2

有点奇怪的问题。设计模式的主要特征之一是其应用的上下文。在我看来，你不是从设计模式开始，而是从上下文开始。

好吧，让我们说，为了论证起见，MVC是您所需要的。你在建什么？网络应用？在这个领域中，工具箱要么是一个框架，要么是一组组件，无论是Struts、Spring、Rails还是Zend (或其他数百个组件)。在大多数情况下，它们已经合并了MVC，您需要遵循既定的方法来完成任务，这样就不会打破MVC的概念。

Answer 3

(这不是对设计工具问题的直接回应，而是对您对MVC跨平台开发的评论的回应。)

MVC模式确实将数据及其紧密关联的逻辑(模型)与业务逻辑( Controller)与显示逻辑(视图)分离开来。

因此，在为OS和iOS编程时，您将能够使用完全相同的模型设计和代码，只需对Controller代码进行非常小的更改，而大部分更改将留在视图端。

在web中添加，如果您使用卡布奇诺网络框架或GNUstepWeb，那么模型端会有更多的更改，但是MVC分离仍然允许大部分控制器代码相同或类似。