MVC 与观察者模式

发布于 2024-07-08 22:07:08 字数 670 浏览 7 评论 0原文

我最近在 StackoverFlow 上问了一个关于 MVC 的问题:MVC 设计模式/架构模式可以用于桌面应用程序开发吗?

根据提供的答案,我开始研究如何在 Windows 窗体应用程序中实现这一点。 我发现了以下 CodeProject 文章: http://www.codeproject.com/KB/ cs/model_view_controller.aspx

在文章下面的评论中,某些用户认为(虽然这是一篇好文章)它实际上是观察者模式。 首先,但不太重要的问题是,是否有人同意或不同意这一点以及为什么?

关于第二个也是更重要的问题:我正在尝试在.NET 中构建一个小型任务列表程序。 它将非常小并且希望很快。 一般来说,对于这样的项目来说,更好的架构是什么? 观察者模式还是 MVC 模式? 或者其他模式?

谢谢

I've recently asked a question on StackoverFlow about the MVC: Can the MVC Design Pattern / Architectural pattern be used in Desktop Application Development?

Based on the answer provided I started research on how this would be implemented in a Windows form Application. I came upon the following CodeProject article: http://www.codeproject.com/KB/cs/model_view_controller.aspx

In the comments below the article, certain users argue that (although this is a good article) it is actually the observer pattern. First, but less important, question is does anyone agree or disagree with that and why?

Regarding the second and more important question: I'm trying to build a small task list program in .NET. It will be very tiny and hopefully fast. In general, what would be a better architecture for such a project? The Observer Pattern or the MVC Pattern? Or another pattern?

Thank you

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

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

发布评论

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

评论(3

○愚か者の日 2024-07-15 22:07:08

(本文不是 MVC AFAIK 的示例,原因很简单,因为没有控制器。如果你问我的话,它更接近 .net 数据绑定。)
MVC 不是观察者模式。 MVC 关注关注点分离。 模型、视图和控制器都只做一项工作,并信任其他人完成他们的工作。 在某种程度上,控制器“指导”视图并告诉它如何对更改做出反应(纯 MVC)。 控制器还与模型进行适当的交互(其职责是封装数据并强制执行约束/规则)。 在 MVC 中,控制器是所有活动的起点 - 用户输入首先由控制器接收。但是也有像 MVP 这样的变体,其中用户输入首先由视图接收,然后与演示者推送/同步。

观察者模式是您想要观察另一个对象的状态变化的地方。 所以你可以说 .net 事件遵循观察者模式

如果它真的很小,那么忘记模式并只需对其进行编码而不用担心架构...遵循良好设计的启发式/原则

如果您遇到设计问题或者开始变得混乱,那么请引入模式营。

(The article is not an example of MVC AFAIK for the simple reason that there is no controller.. it is more close to .net data binding if you ask me.)
MVC is not the Observer pattern. MVC is concerned with separation of concerns. The Model, the View and the Controller all do one job and trust the others to do theirs. In a way, the Controller 'directs' the view and tells it how to react to a change (Pure MVC). The controller also interacts with the model appropriately (whose responsibility is to encapsulate data and enforce constraints/rules). In MVC, the controller is the starting point for all activities - user input is received by the controller first.. However there are variants like MVP, where the user is input is received by the view first and then pushed/synched with the presenter.

The Observer pattern is where you want to watch another object for a change in state. So you could say .net events follow the observer pattern

If its really tiny, forget about patterns and just code it up without worrying about the architecture... Follow the heuristics/principles of good design

If you run into design issues or it starts to get all messy, then bring in the pattern battalions.

不必你懂 2024-07-15 22:07:08

我同意这篇文章不是 MVC。 它更多的是观察者模式的实现。 .NET 中的观察者模式可以通过使用事件来实现,本文就是这种情况。

MVC 需要一个控制器类来控制根据模型或视图发出的请求执行哪些操作。 应用 MVC 是一种非常好的编程实践,因为它极大地促进了关注点分离。 使用 MVC,您将拥有一个更干净、更可扩展且更可测试的应用程序。 另一点需要注意的是,您仍然可以将观察者模式应用于 MVC 应用程序。 他们不会相互矛盾。

===========

回答你的第二个问题:哪种模式最好? 我认为您进行软件开发的方式是相当错误的。 在遇到问题之前,您不应该太担心这些事情。 例如,如果这个对象改变状态,我需要其他对象对其做出反应,因此我将实现观察者模式。

如果我是你,我会首先从模型方面开始,然后从那里开始。

I would agree that the article is not MVC. Its more of an implementation of observer pattern. Observer pattern in .NET can be implemented by using events, which was the case of the article.

MVC requires a controller class that controls what action to execute upon a request made from either the model, or the view. Applying MVC is a very good programming practice as it greatly promotes separation of concern. You will have a cleaner, more extensible, and more testable app with mvc. Another point to note, you can still apply observer pattern to an MVC app. They will not contradict each other.

===========

To answer your second question: which pattern is the best? I think the way you approach software development is rather wrong. You shouldn't worry too much about those things yet, not until you've hit a problem. e.g. If this object changes state I need these other objects to react to it, hence I would implement an observer pattern.

If I were you I would start on the model side first, and then takes things from there.

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