MVC 大型网站，使用一个控制器...还是多个？
我有一个相当大的网站，我正在寻找最省时的方法来管理它（我是唯一的编码员）。
我正在尝试设计一个非常简单的 MVC 结构（我不想使用框架）来帮助保持所有代码有序。
对于一个巨大的网站，是只用一个控制器来处理所有页面更好，还是将它们分开更好、更容易？
如果只有一个，非框架控制器的一个很好的例子是什么？
I have a pretty large site, and I am looking for the most time efficient way to manage it (I am the sole coder).
I am trying to devise a very simple MVC structure (i don't want to use a framework) to help keep all my code in order.
For a huge site, is it better to have only one controller to handle all the pages, or is it better and easier to split them up?
If just one, what is a good example of a non-framework controller?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（5）
我会将任何逻辑分区拆分为不同的控制器 - 如果都是静态页面，则使用所有相同的“静态页面”控制器来提供它。
如果您有一些静态页面、常见问题解答页面（或部分）、产品列表 - 为每个不同的部分使用控制器。因此，静态页面将由一个控制器从平面文件或数据库中提取，常见问题解答页面将由另一控制器从常见问题解答表生成，产品和信息将由任何来源生成。
每次生成页面或访问数据的方式时，都使用不同的控制器。
当然，类继承可用于使用任何控制器所需的代码创建基类。
不确定非框架控制器是什么意思 - 我会检查 Zend（喘息）“框架”、MVC 模式，甚至控制器本身，都可以与框架的其余部分分开使用。
I would split any logical divisions into different controllers - if it's all static pages, then serve it up with all the same 'static page' controller.
If you have some static pages, a FAQ page (or section), a product list - use a controller for each different section. So the static pages would be pulled from flat files or a database by one controller, the FAQ pages would be generated from a FAQ table by another controller, the products and info would be generated by whatever the source for that is.
Every time the way a page is generated or the data is accessed, use a different controller.
Of course, class inheritance can be used to create the base class with the code needed by any controller.
Not sure what you mean by a non-framework controller - I'd checkout the Zend (gasp) 'Framework', the MVC pattern, and even the controller itself, can be used apart from the rest of the framework.
我倾向于根据控制器对站点/应用程序的特定部分的职责来拆分它们。这使得维护代码变得更加容易。此外，我将控制器（以及视图、模型）分组到模块（文件夹）中。以下是我当前正在处理的项目的示例：
网站越复杂，我使用的模块就越多。虽然我的大多数模块只包含一个“索引”控制器，但我确实喜欢它们提供的组织。
然后我使用路由器（前端控制器）将 REST 样式 URI 映射到正确的模块/控制器/操作。例如：mysite.com/blog/posts/view/7 将从“blog”模块调用 Controller_Posts::view(7) 。使用模块的另一个好处是，与没有模块相比，我可以拥有更具体的 URI。虽然我认为可以通过使用支持定义自定义路由的路由器来解决这个问题，但我不太喜欢这样做。
与许多其他事情一样，这归根结底取决于您作为开发人员对什么感到满意，但我们可能会同意，只要您不让事情变得过于复杂，您拥有的组织越多，您的生活就越好。
顺便说一句，我建议您考虑使用框架。如果您不想使用现有的其中一种，我理解，因为我也避免使用它们。我最终写了自己的，在过去的一年里，这对我很有帮助。这是一次很棒的学习经历，它只包含我想要/需要的内容。话虽这么说，您可能想看看 Kohana 和 CakePHP - 在我看来它们并不过分臃肿，如果您决定不编写自己的，它们肯定会节省您的时间。
I tend to split the controllers up based on their responsibility to a specific section of a site/application. This makes maintaining the code so much easier. Furthermore, I group controllers (and views, models) within modules (folders). Here's an example from a current project I'm working on:
The more complex a site, the more modules I use. Although most of my modules only contain one 'Index' controller, I do like the organization they provide.
Then I use a router (front controller) that maps a REST style URI to the proper module / controller / action. Ex: mysite.com/blog/posts/view/7 would call Controller_Posts::view(7) from the "blog" module. An added benefit of using modules is I can have more specific URIs than if I didn't have modules. Although I suppose that could be remedied by using a router that supports defining custom routes, but I'm not too fond of that.
As many other things, it boils down to what you're comfortable with as a developer, but we can probably agree that more organization you have, the better off you are, so long as you don't over complicate things.
As a quick aside, I would recommend you look into using a framework. I understand if you don't want to use one of the ones out there already, as I avoided those too. I ended up writing my own which for the past year has served me very well. It was a great learning experience and it only contains what I want / need. That being said, you might want to look into Kohana and CakePHP - they're not overly bloated IMO and they will definitely save you time should you decide not to write your own.
通常，人们将控制器分为专注于特定功能领域的控制器。
然后他们在所有内容前面放置一个“前端控制器”，因此应用程序只有一个入口点。前端控制器的唯一工作是将传入请求路由到适当的控制器。
查看 Zend_Controller 组件的设置方式。它可以提供您需要的一切，并且您可以自由使用它，而无需购买完整的 Zend 框架。
Typically people split up controllers into controllers focused on specific areas of functionality.
Then they stick a "front-controller" in front of it all, so there's only one entry point to the application. The front-controller's only job is to route incoming requests to the appropriate controller.
Look at the way the Zend_Controller component is set up. It may provide everything you need, and you're free to use it without buying into the complete Zend Framework.
这取决于其他部分如何工作。如果您只有一个模型文件，那么可能不值得拆分控制器。如果您可以将模型和控制器分成多个部分，那么就这样做。
然而，我经常发现模型之间有太多重叠而无法将它们分开。您可能有一个文章模型，但如果您想在其他页面的侧边栏中显示前 20 篇文章，该代码应该位于文章模型中 - 并且您在每个页面上都需要它。
但老实说，唯一的方法就是尝试一下。从单个入口点开始，如果它变得太笨拙，请将其重构为更小的块。
It depends how you other parts will work. If you only have one model file then it's probably not worth splitting up the controller. If you can split up the model into sections as well as the controller, then do that.
However, I often find that there's too much overlap between models to separate them. You might have a model for articles, but if you want to display the top 20 articles in a sidebar on other pages, that code should be in the article model - and you're going to need that on every page.
Honestly though, the only way to do it is try it and see. Start with a single entry point, and if it gets too, unwieldy, refactor it into smaller chunks.
我的建议是一台路由器/调度程序，多个控制器。控制器应该映射到 URL，这意味着不同的功能。控制器将与不同的服务协作来完成每个用例，因此如果您的应用程序有多个用例，则整个应用程序的一个控制器将变得太笨重。
One router/dispatcher, many controllers would be my advice. Controllers ought to map to URLs, which means differing functionality. A controller will collaborate with different services to accomplish each use case, so one controller for your entire app would become too unwieldy if your app has more than a handful of use cases.