正确组织和构建中型 PHP 项目

发布于 2024-12-11 12:43:05 字数 358 浏览 1 评论 0原文

我用 PHP 为一所小型私立学校编写了一个学习管理系统。不久前,当时很多编程知识对我来说都是新的。它主要是基于脚本和包含的,不包含类或任何 MVC 风格的组织,但它已经变得很大。我想做的就是在不重写的情况下组织当前的代码,这样有利于快速迭代。

到目前为止,我对其进行了更改,以便每个角色都有自己的文件夹/索引/操作,并且所有角色都使用一个共享的 lib.php 文件来执行 sql 查询和其他相关操作。

我与几个 MVC 人员交谈并考虑将 PHPCake 和 Tonic 作为一种选择,但这些似乎极大地改变了我已经拥有的东西。我不确定这是否只是在我的实践中,但我只是不明白 MVC 将如何让我更轻松地更快地开发。有人可以提供提示或经验建议/意见或者一些有用的链接。谢谢。

I wrote in PHP a learning management system for a small private school. It started a while ago when a lot of programming stuff was new to me. It is mostly scripts and includes based and doesn't contain classes or any MVC style organization, but it has grown big. What I am trying to do is to organize the current code without rewriting, so that it is good for fast iterations.

So far I changed it so that every role has its own folder/index/actions and all of them use one shared lib.php file to do sql queries and other related actions.

I talked to couple of MVC folks and considered PHPCake and Tonic as an option, but those seem to change dramatically what I already have. I am not sure if it just in my practice, but I just don't see how MVC will make it easier for me to develop faster. Can someone give tips or experience advise/opinions or maybe some helpful links. Thanks.

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

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

发布评论

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

评论(3

饮惑 2024-12-18 12:43:05

MVC 是一个有用的框架,可以以某种“自然”的方式将应用程序开发为逻辑上独立的组件。它可以提高您快速开发的能力,主要基于框架的某些部分最终将可重用的事实,并允许您利用这一事实来快速开发新的视图和类似的视图。然而,没有必要使用任何特定的框架或方案来快速开发,因为可以通过任何性质的正确设计的应用程序来完成。

以这种方式开发应用程序时需要考虑的一个重要事项是代码重用。例如,通过集中机制简化显示具有通用布局的页面,或者将与用户相关的功能放入用户类/功能集中,可以在站点范围内重用,而不是在每个页面上使用单独的功能来处理它。

在修改现有应用程序方面,我将专注于尝试集中您能够使用的组件并在以后使用这些组件。这也使得修改例程变得更加简单,因为您可以在单个位置更改它并影响整个应用程序,而不是潜在地更改代码库许多区域的功能。

MVC can be a useful framework for developing applications into logically separated components in a somewhat 'natural' way. It can increase your ability to develop quickly based mainly off the fact that some portions of the framework will end up being reusable and allow you to leverage that fact to develop new views and similar quickly. However, it is not necessary to use any particular framework or scheme to develop quickly as it can be done with a properly designed application of any nature.

An important thing to consider when developing an application in such a manner is code reuse. For example, making it simple to display pages with common layouts through a centralized mechanism, or having user-related functions placed into a user class/function set which can be reused site-wide instead of having individual functionality to handle it on each page.

In terms of modifying an existing application, I would focus on trying to centralize the components you are able to and making use of those components henceforth. This also makes modifying routines simpler because instead of potentially changing functionality on many areas of the codebase, you can change it in a single location and effect the application as a whole.

黯然 2024-12-18 12:43:05

试图让模式适合问题是一种非常愚蠢的方法。模式是代码的本质,而不是代码应该是什么。在任何呈现用户界面的面向对象项目中,都会有模型、视图和控制器的实例 - 但代码中也会有许多其他模式 - 观察者、装饰器、迭代器等等。它们是有用的学习结构(例如“这里是如何实现工厂以从关系数据构建对象”)和(人类)语言结构(例如“数据库连接类应该作为单例实现”)。它们不是设计构造。

这样每个角色都有自己的文件夹/索引/操作

除非您对“角色”有一个相当不寻常的定义,否则这种架构没有任何意义。划分高级功能的最常见标准是关注点分离和围绕公共数据源进行分组。

您提到了框架 - 尝试调整现有代码以适应框架通常是一个坏主意 - 它不适合。如果您从项目一开始就使用它们,它们将有助于构建您的应用程序并减少工作量。不是从中间/末端开始。

Trying to make a pattern fit a problem is a very silly approach. Patterns are what code is not what what the code should be. In any object-oriented project presenting a user interface there will be instances of models, views and controllers - but there will also be lots of other patterns in the code - observers, decorators, iterators and more. They are useful learning constructs (e.g. "Here's how to implement a factory to build objects from relational data") and (human) language constructs (e.g. "That database connection class should be implemented as a singleton"). They are not design constructs.

so that every role has its own folder/index/actions

Unless you've got a rather unusual definition of 'role', this architecture makes no sense. The most common criteria for dividing up high-level functionality are separation of concerns and grouping around common data sources.

You've mentioned frameworks - trying to adapt existing code to fit into a framework is usually a bad idea - it won't fit. They can be of benefit in structure your application and reducing the amount of effort if you sse them from the start of the project. Not from the middle / end.

逆夏时光 2024-12-18 12:43:05

测试您编写的新代码。由于旧代码不是这样,因此也将其逐部分进行测试。现在您已经对所有内容进行了测试,您应该可以进行更快的迭代。

Put the new code you write under test. As the old code isn't, put it under test part-by-part as well. At the moment you've put everything under test, you should be fine for faster iterations.

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