MVC中的M在哪里?

发布于 2024-11-15 20:16:07 字数 1076 浏览 3 评论 0原文

我要问的问题的灵感来自于我最近使用 Flex 平台(以及一些假装实现 MVC 的框架)的工作,但我认为它足够普遍,足以让具有各种专业知识的人参与进来。

在相当多的时间里,我一直遵循 Cairngorm -

View 等框架提出的范例,绑定到单例模型的属性,并调度事件。 事件被前端控制器捕获,命令因此被执行。 命令调用服务、获取数据并提供模型。 模型通过绑定隐式更新视图。

一切都很好,直到我得到以下数据结构:

User 有很多关注者(用户) 关注许多用户 有一堆照片 跟随许多地点

照片 有很多喜欢的人(用户) 有一个位置 有一个创造者 有很多相关照片

位置 有很多照片 有很多追随者

同样,使用 Cairngorm 提出的想法也不会有问题,例如 currentUser、currentLocation 和 currentPhoto,然后绑定到它们。

问题出在观点本身。我有一系列复杂的“页面”视图,正如人们可以想象的那样,它们提供了钻取的信息。例如,位置页面显示最新/热门照片的网格、关注者的面板以及基于拍摄这些照片的坐标的地图。问题来了:

显然,出于性能原因,我无法获取关注特定位置的所有用户,或某个位置可能拥有的所有照片。我已经预取了一些,其他的将由服务器按需提供。

我想深入了解同一视图,例如,当单击关注者的头像页面时,我应该获得该用户照片或其他内容的小网格。但我的模型中只有一个 currentUser 。

这就引出了一个问题,为什么我需要绑定到中央单例模型?我不能将每个视图变成某种响应程序吗?即视图再次调度偶数,但这次命令将直接提供调用视图,而不是提供模型。

不会有任何耦合,因为每个视图都会实现 IResponder。该命令只需要一个 IResponder,它将从调用它的事件中获取。

在我看来,“模型”将发挥不同的作用。它将更像是一个缓存,一个用于本地存储的全局字典的排序,在向服务器发出请求之前将由命令检查。这样,它可以节省对服务器的一些调用,但是,如果数据非常零散,那么相同的数据将与其他数据一起一次又一次地获取。 (我可能在缓存中有一些用户数据,但通常我会调用服务器来收集关注者数据,无论我是否已经拥有其中一些数据,以保持一致性)

对这些想法的任何反馈将不胜感激

The question I am going to ask was inspired by my latest work with the Flex platform (and some frameworks pretending to implement MVC), but I think it's general enough to involve people with various expertise.

For quite a lot of time I have followed the paradigms, proposed by frameworks like Cairngorm -

View, bound to properties of a singleton model, and dispatching events.
Events get caught by the front controller, and commands get executed as a result.
commands call services, get data, and supply the model.
The model implicitly updates the views through bindings.

It was all nice and sound until I got to the following data structure:

User
has many followers (Users)
follows many Users
has a bunch of photos
follows many locations

Photo
has many likers (User)
has a location
has a creator
has many related photos

Location
has many photos
has many followers

Again, it would not be a problem to use the idea proposed by Cairngorm, for instance to have
a currentUser, currentLocation, and currentPhoto, and just bind to them.

The problem comes in the views themselves. I have a series of complex "page" views, which provide as drilled information, as one could imagine. For instance, the location page, shows a grid of latest/popular photos, a panel for for followers, and a map of based on the coordinates where those photos were taken. Here come the problems:

Obviously, for performance reasons, I cannot fetch all users that are following a particular location, or all photos a location could have. I have pre-fetched some, and others will supplied by the server on demand.

I want to drill-down staying on the same view, for example when clicking on a follower's avatar page, i should get a small grid of that user's photos, or sth. But i only have one currentUser in the model.

This leads to the question, why do i even need to bind to a central singleton model? Can't I just turn every view into a sort-of responder, i.e the view dispatches an even again, but this time the command instead of supplying the model, will supply the calling view directly.

There won't be any coupling because every view will implement IResponder. The command will require only an IResponder, which it will get from the Event it was called with.

The "model" as I see it, will play a different role. It will be more like a cache, a sort a global Dictionary for local storage, which will be checked by the command before it makes a request from the server. This way it may save some calls to the server, although, if the data is very sporadical, this same data will be fetched again and again together with other data. (I may have some user data in the cache, but in general I will call the server for a collection of follower data, regardless of whether some of it I might already have or not, for consistency )

Any feedback on these ideas will be appreciated

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(2

上课铃就是安魂曲 2024-11-22 20:16:07

我认为你真正的问题是这样的:

这引出了一个问题,为什么我
甚至需要绑定到中央
单例模型?

您不需要绑定到中央单例模型。事实上,许多人声称这种方法很糟糕,并且会导致性能问题。绑定可能是一项昂贵的操作,因此将所有可绑定值放在一个位置可能会在您的应用程序中产生连锁反应。

事实上,凯恩戈姆似乎将你推向这个方向,这是对凯恩戈姆的常见批评。在 Cairngorm 的辩护中,我认为在 Cairngorm 架构内,如果你愿意的话,你没有理由不能拥有多个“全局数据单例”。首先,我不会重复反对单身人士的论点。

大多数后凯恩戈姆框架都可以被视为对凯恩戈姆的回应,并尝试以不同的方式做事。

I think your actual question is this:

This leads to the question, why do i
even need to bind to a central
singleton model?

You don't need to bind to a central singleton Model. In fact, many claim this approach is horrible and will cause performance issues. Binding can be an expensive operation, so putting all the bindable values in one place can cause ripple effects in your app.

The fact that Cairngorm seems to push you in this direction is a common criticism for Cairngorm. In Cairngorm's defense, I see no reason why--within the Cairngorm architecture--you can't have multiple "global data Singletons" if you want. I'll refrain from regurgitating the arguments against Singletons in the first place.

Most post-Cairngorm frameworks can be seen as a response to Cairngorm and an attempt to do things differently.

画骨成沙 2024-11-22 20:16:07

这并不是真正的答案,因为这个问题并不是真正的问题。然而,如果您想了解“MVC”,您应该远离 Cairngorm,因为它可能实现了所有 Flex 应用程序框架中最糟糕的 MVC 模式。最好的例子之一(或者最坏的例子,取决于你如何看待它)是他们使用单例模型,Theo 已经发表了博客

您应该查看 RobotLegsParsley 用于正确的 MVC 架构。在我个人对建筑的看法中,“模型”只是“数据”的另一种表达方式。它只是一个保存应用程序数据或状态的类。

This isn't really an answer because the question isn't really a question. However, if you want to look at 'MVC', you should stay far far away from Cairngorm since it implements probably the worst MVC pattern in all application frameworks for Flex. One of best example (or worst depending how you look at it) of this is their use of the singleton model which Theo already blogged about.

You should look at RobotLegs or Parsley for a proper MVC architecture. In my personal opinion of architecture, the 'model' is just another way to say 'data'. It's just a class that holds data or state for your application.

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文