在MVC中,你把对你的模型类的引用放在哪里?[英] In MVC where do you put references to your model Classes?

本文是小编为大家收集整理的关于在MVC中,你把对你的模型类的引用放在哪里?的处理/解决方法,可以参考本文帮助大家快速定位并解决问题,中文翻译不准确的可切换到English标签页查看源文。

问题描述

我已经想知道一段时间了,在问不同的人之后,没有任何人提供我所说的"至少有点具体答案":

问题:

在iPhone应用程序中,应用程序应保留对其模型类的参考(使用 mvc 方法)?

在iPhone(和可可)应用程序中,我们拥有所谓的"应用程序委托",基本上启动了我们的应用程序并加入了我们的控制器,还处理了Uitouch事件.

那么,应用程序是否会委派控制器?模型类?没有两个?我认为不知道这也让人感到困惑,因为它知道将模型参考放在哪里.

示例:

您有应用程序委托,该委托包含对您应用程序视图控制器的引用.如果我的应用程序将使用Model A类(是Web服务器守护程序类),并且B类存储该Web服务器查询的数据.

你们将在哪里存储对A和B的引用? (App委托?查看控制器?两者?)

这里有很多选项,但例如,我真的很想知道你们将如何使用MVC组合此应用程序,该应用程序仅使用一个视图.

推荐答案

很容易将所有内容放入AppDelegate中,但是如果您开始这样做,那么您的AppDelegate将充满参考黑客.如果您正在执行严格的MVC,那么您应该有3件事:

  • 模型
  • 视图控制器(仅用于查看逻辑)
  • 一个控制器(用于在视图和模型之间进行协调)

因此,例如,我有一个模型foo和一个foo控制器.我会:

  • foo.m(型号)
  • fooviewcontroller.m(显示一个foo)
  • foocontroller.m(控制逻辑)

最后,为了回答您的问题,我将对FOO的参考存储在FOO控制器中.我喜欢将单身人士用于控制器,但这只是我.如果您确实使用Singleton,则可以做这样的事情:[[FooController sharedInstance] listOfFoos]以获取Foo的

其他推荐答案

在我的应用程序中,我通常会将AppDelegate类重命名为AppController,如果这有助于在概念上更好地解释事物.您的应用程序控制器负责创建和/或配置模型控制器(管理您的模型对象的集合)和窗口或查看控制器,在需要时设置引用,并在这些控制器上调用这些控制器,以响应NSApplication委托方法或主菜单中的高级操作方法.根据您的应用程序的复杂程度,您可能还具有其他模型或视图控制器,这些模型或视图控制器是在应用程序控制器之外创建的.

当然,如果您有一个简单的应用程序,则没有真正的理由不让您的应用程序控制器在需要的情况下扮演模型控制器的角色.您要避免的是使用数百行代码的文件,所有代码都在做概念上无关的任务.

其他推荐答案

传统上,控制器创建模型,然后使用该模型初始化视图.然后,控制器会听取模型和查看的更改,并通过此操作协调程序的流程.那将是我的通用答案,也许实践中的事情对于iPhone开发会有所不同.

本文地址:https://www.itbaoku.cn/post/627419.html

问题描述

I have been wondering for a while, after asking different people and without any of them providing what I would call an "at least a bit concrete answer":

Question:

Where, in an iPhone application should an application keep the references to it's Model Classes (using the MVC approach) ?

In iPhone (and Cocoa) applications we have what we call the "App Delegate", which basically start's up our application and inits our controllers, also handles UITouch events.

So is the App Delegate a controller ? a model class ? none of the two ? I think not knowing that also makes confusing to know where to put the Model References.

Example:

You have the Application Delegate, that delegate contains a reference to your Application's View Controller. If my Application would use Model Class A ( which is a webserver daemon class ), and a Class B which stores data queried by that webserver.

Where would you guys store the references to A and B ? (App Delegate ? View Controller ? Both ? )

There are many options here, but as an example, I would really like to know how would you guys use mvc to put together this application which only uses one View.

推荐答案

It is tempting to put everything in the AppDelegate, but if you start doing this, then your AppDelegate will be full of reference hacks. If you are doing a strict MVC, then you should have 3 things:

  • A Model
  • A View Controller (Only for view logic)
  • A Controller (For coordinating between the view and the model)

So for example, I have a model Foo and a Foo controller. I would have:

  • Foo.m (Model)
  • FooViewController.m (Displays a Foo)
  • FooController.m (Controls the logic)

And finally, to answer your question, I would store my references to Foo's in the foo Controller. I like to use singletons for my controllers, but thats just me. If you do use a singleton, you can just do something like this: [[FooController sharedInstance] listOfFoos] to get your Foo's

其他推荐答案

In my applications I usually rename the AppDelegate class to AppController, if that helps explain things better conceptually. Your app controller is responsible for creating and/or configuring the model controller (which manages your collection of model objects) and window or view controllers, setting up references between them if needed, and calling methods on these controllers in response to NSApplication delegate methods or high level action methods from the main menu. Depending on how complex your application is you might also have additional model or view controllers which are created outside your app controller.

Of course if you have a simple application there's no real reason not to have your app controller play the role of the model controller if you want. What you want to avoid is file with hundreds of lines of code, all doing conceptually unrelated tasks.

其他推荐答案

Traditionally the controller creates the Model and then initialises the View with that model. The controller then listens to changes in the model and view and coordinates the flow of the program through this. That would be my generic answer, maybe things in practice would be different for iPhone development.