想要了解 MVC 模型，有建议吗？
我正在编写自己的 MVC，目的是为了学习它。除了模型之外，我几乎把所有东西都“按下去”，并且我写的主要内容是由于理解它们时遇到一些困难并且缺乏可行的示例。
现在，我被告知模型应该代表单行，有人告诉我，你的模型类应该更新/插入和删除行，任何涉及获取单行或多行的内容 - 应该使用“查找器”类。
那么... a) 什么是 finder 类，b) 如何在使用示例中实现它，c) 我所了解到的有关模型的信息是否正确，或者是否有比“finders”更好的方法？
建议很实用:)
I am writing my own MVC for the purpose of learning it. I have pretty much everything "down-pat" and my main stuff written besides models due to some trouble understanding them and lack of viable examples.
Now, I've been told a model should reprecent a single row, someone told me, your model class should on update/insert and delete rows, anything that involves fetching a single or multiple rows - a "finder" class should be used.
So... a) what is a finder class, b) how do I implement it in a useage example, c) Is what I've been told about models correct or is there a better way than "finders"?
Advice is much appricated :)
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（4）
人们普遍误解 MVC 中的 M 只是与数据库有关。 MVC 的主要目标是以 M 不了解 VC 的方式将表示层与其余应用程序分离。
V 和 C 构成 UI，用户可以通过它与应用程序交互的外层。 C 处理来自 V 的所有输入请求，并在需要时委托给 M。 V显示M的变化。在基于Web的MVC中，V在内容、表示和行为上进一步分离，例如HTML、CSS和JavaScript。
应用程序本身位于 M 内部。它应该能够与 UI 隔离运行。因此，它不仅包含数据访问层，还包含几乎所有其他层，但还包含表示层。它可以（但可能不）包含 DAL、服务层、域对象等 - 无论您的应用程序需要什么，无论是从 RSS 源获取数据、将数据推送到 Web 服务、发送电子邮件或计算收入等
。 DAL 应该代表一行、一个表或其他由您决定的东西。它是您的架构的重要设计选择。四种常见模式是表数据网关、行数据网关、活动记录和数据映射器。
请查看 http://martinfowler.com/eaaCatalog/index.html 了解概述。
It is a common misconception that the M in MVC is just about the database. MVC's main aim is to separate the presentation layer from the remaining application in a way that M does not know about VC.
V and C form the UI, an outer layer by which users can interact with your application. C handles all input requests from V and delegates to M where needed. V displays changes in M. In webbased MVC, V is further separated in content, presentation and behavior, e.g. HTML, CSS and JavaScript.
The application itself is inside the M. It should be able to run isolated from the UI. As such, it does not comprise only the Data Access layer, but virtually all other layers, but the presentation layer. It can, but may not, contain DALs, Service Layers, Domain objects, etc. - whatever is necessary for your application, be it getting data from an RSS feed or pushing data to a Webservice or sending eMails or calculating Revenue, etc.
Whether a DAL should represent a single row, a table or something else is up to you. It's an essential design choice for your architecture. The four common patterns are Table Data Gateway, Row Data Gateway, Active Record and Data Mapper.
Check out http://martinfowler.com/eaaCatalog/index.html for an overview.
答案是简单的“视情况而定”。
模型不必表示单行或行集合（我假设您在这里讨论的是数据库数据）。您的模型应该用于映射您的业务逻辑实体。只有模型数据的子集需要持久性，这可以通过与数据库交互来实现。
如果我们参考 Doctrine 案例，这就是为什么即将推出的 Doctrine 2 不会强制您的模型从 Doctrine 记录基类扩展。
我相信这就是为什么像 Zend Framework 这样的 MVC 框架没有为您提供“Zend_Model”概念。您的模型应该根据具体情况进行实施。
The answer is the plain old "it depends".
A model does not have to represent a single row or a collection of rows (I presume you are talking about database data here). Your model should be used to map your business logic entities. Only a subset of your model data require persistence, which could be achieve by interacting with a database.
If we refer to the Doctrine case, this is why the upcoming Doctrine 2 does not force your models to extend from a doctrine record base class.
And I believe this why MVC frameworks like Zend Framework does not provide you with a "Zend_Model" concept. Your models should be implemented case to case.
CakePHP 说：
(http://book.cakephp.org/view/66/Models)
基本上，该模型代表业务数据的持久存储。通常，这是一个数据库。
一旦我们开始谈论数据库和对象，它通常会陷入备受争议的“对象关系映射”领域，即许多 PHP 框架如何实现模型。
模型通常代表表中的一行，但也可以是多个表中的一组行。模型可以用无数种方式表示：从像 Doctrine 一样复杂且臃肿的东西db 对象是像文本文件这样简单的东西。
我首选的表示模型的方式是主表上每个模型一行，与任何相关的父表连接并包含任何子表的成员对象。有效实现这一点的唯一方法是使用某种“Collection”类，以便可以立即获取所有对象，这样您就不会进行不必要的查询。
编辑：为了直接回答您的问题，是的，如果您想最大限度地减少访问数据库的次数，“查找器”或“集合”类绝对是必要的。如果每个模型都是自给自足的，那么您将执行数百个单独的“SELECT FROM table WHERE id=x”查询。查找器或集合只能选择多行并将数据转储到模型对象中。
CakePHP says:
(http://book.cakephp.org/view/66/Models)
Basically, the model represents persistent storage of your business data. Normally, this is a database.
Once we begin talking about databases and objects, it usually falls into the realm of the much debated 'object-relational mapping' which is how many PHP frameworks implement Models.
A Model usually represents a row in a table, but it could also be a group of rows from multiple tables. A Model could be represented in an infinite number of ways: from something as complex and bloated as a Doctrine db object to something as simple as a text file.
My preferred way of representing models is one-row per model on the main table joined with any related parent tables and containing member objects of any child tables. The only way to effectively implement this is to use a 'Collection' class of some sort so that all the objects can be fetched at once and so you don't make unnecessary queries.
Edit: To directly answer your question, yes, a "finder" or "Collection" class is absolutely necessary if you want to minimize the number of trips to a database. If each model was self sufficient, you'd be doing hundreds of individual 'SELECT FROM table WHERE id=x' queries. A finder or Collection can just SELECT multiple rows and dump the data into Model objects.
您可以将查找器实现为模型类的静态方法：
$foo = ModelFoo::find($id)You could implement finders as static methods of the model class:
$foo = ModelFoo::find($id)