为我的应用程序构建 MVC 的正确方法
我正在从三个搜索引擎中抓取数据。在我的querys_controller 中，我将有一个调用$this->Query->find('$query') 的函数搜索。我的模型会将其传递到我自己的数据库，其 read() 函数将调用三个函数：searchGoogle($query)、searchYahoo($query) 和 searchBing($query)。返回值将由数据库中定义的一些辅助函数标准化，然后添加到 read() 返回的数组中。我的模型将简单地将这些信息传递到控制器上，控制器将其显示在视图中。同时，控制器将使用一个额外的模型将查询的所有结果写入 MySQL 数据库，该模型将调用该模型的 write() 函数。
所有功能都在数据库中是否正确，还是数据库应该返回粗略内容并将其留给模型进行标准化？我的模型会让另一个模型将其写入数据库还是控制器？我在数据库中有帮助程序来进行标准化吗？是否有类似函数扩展之类的东西，以便它们都具有相同的返回数组？我可以定义我的搜索函数使用的数组必须具有的内容吗？
I am scraping data from I want to scrape three search engines. In My queries_controller I will have a function search that calls $this->Query->find('$query'). My Model will hand this onto my own Database whose read() funcion will call three functions, searchGoogle($query), searchYahoo($query) and searchBing($query). The return values will be standartized by some helper functions defined within the Database and then be added onto the array that read() returns. My model will simply pass this information onto the controller which will display it in a view. At the same time the controller will write into a MySQL Database all results of my query with an extra model whose write() function it will call.
Is it right that all functionality will be in the database or should the database return the rough content and leave it to the model to standartize it? Woud my model have another model write it to a database or would it be the controller? would I have helpers in the database to do the standartizing and is there something like extends for functions so they all have the same return array? Can I define what an array has to have that my search functions use?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
听起来你在这里进行了很多抽象，但我无法判断这是否是真正的抽象，如果你只是模糊地使用几个术语（例如“助手”）。一般来说，您的模型会与您的数据源对话。该数据源可以是数据库、服务、平面文件或任何/所有这些的某种组合。我经常使用外部服务来收集大部分模型数据，然后使用从专门数据库中提取的一些以应用程序为中心的数据来充实这些数据。
帮助程序通常出现在视图级别并帮助您显示数据。我自己的偏好是模型将原始数据返回到控制器，控制器将相同的原始数据转发到视图，视图负责弄清楚如何显示它。这种流程有时会出现例外情况，但在我自己的使用模式中很少见。
简短版本：让事情变得简单（并且符合惯例）。让您的控制器处理应用程序流和以应用程序为中心的活动（例如消息传递、会话访问等），让您的模型处理数据访问/检索/操作，并让您的视图担心如何显示从模型返回的数据（通过控制器）。
在此基础上添加更多抽象通常只会增加不必要的复杂性。由于对您的情况没有任何真正的了解，这只是指导，但根据我自己的经验，我发现它通常是可靠的指导。
It sounds like you've got an awful lot of abstraction going on here, but I can't tell if it's real abstraction of if you're just using a few terms (e.g. "helper") ambiguously. Generally speaking, your model would talk to your datasource. That datasource could be a database, a service, a flat file or some combination of any/all of those. I regularly use an external service to gather most of the model data and then flesh that out a bit with some application-centric data pulled from a specialized database.
Helpers generally appear at the view level and help you to display the data. My own preferences is for the model to return raw data to the controller which forwards that same raw data onto the view which is responsible for figuring out how to display it. There are exceptions to that flow from time to time, but they're pretty rare in my own usage patterns.
Short version: keep things simple (and within convention). Let your controller handle application flow and application-centric activities (e.g. messaging, session access, etc.), let your model handle data access/retrieval/manipulation and let your view worry about how to display the data returned from the model (through the controller).
Adding more abstraction on top of that is generally just adding unnecessary complexity. Without any real knowledge of your situation, this is only guidance, but I've found it to be generally solid guidance in my own experience.
请记住，CakePHP（以及大多数 MVC 架构）的最佳实践是：
话虽如此，将功能放入模型中也不错，只要它适用于您正在操作的数据即可。将模型视为处理所有数据特定问题（即存储、查询、操作、优化等）。控制器处理所有业务逻辑，视图管理两者组合的显示。
帮助程序旨在促进视图功能，而元素是可重用的视图。
至于其余的问题，如果您遇到困难，将它们分解为带有代码示例的单独问题可能会更简单。
Keep in mind, the best practice for CakePHP (and most MVC architectures in general) is:
That being said, putting functionality into the Model is not bad, as long as it is applicable to the data you are manipulating. Think of the Model as handling all of the data specific issues (i.e. storage, queries, manipulation, optimization, etc.). The controller handles all of the Business Logic, and Views manage the display of the combination of the two.
Helpers are designed to facilitate view functionality while elements are reusable views.
As for the rest of your questions, it may be simpler to break them out into individual questions with code samples if you are getting stuck somewhere.
一般来说，您希望避免数据库中有逻辑。数据库应该负责返回数据，然后模型将负责做它需要做的事情。扩展数据库比添加更多处理能力要困难得多。除了可扩展性问题之外，数据库中的代码更难以维护。
In general you want to avoid having logic in your database. The database should be responsible for returning the data and then the Model will be responsible for doing whatever it needs to. It is much more difficult to scale the database than to add more processing power. Code in the database is much more difficult to maintain in addition to scalability concerns.