use*_*913 4 php architecture performance coding-style scalability
我有一个PHP应用程序,有大约50-55个代码文件.具有最大代码量的文件具有大约1200行代码(这包括空格,制表符和多个换行符......),其余代码文件相对较小.
几乎每个文件中的应用程序代码都是html,sql和php(你称之为spaghetti)的混合,除了一些纯php包含文件的文件....例如包含许多其他函数所需的函数的文件地方.
我一直在考虑将这个应用程序重构为mvc类型架构是否是一个好主意.
现在我知道mvc应用程序提供了许多优点,如易于维护,重用和易于进一步开发等,但是可伸缩性和性能如何 - 特别是在这种情况下？
我的假设是,因为这是一个小应用程序(我相信如此,你认为它足够小吗？),我不认为很难进行维护或增加一些功能(最多),这可能意味着在现有文件中添加一些内容,或者可能添加最多5-10个新文件.
所以我想我不应该为了维护而转换为mvc.
据我所知,你可以将mvc的每个组件放在一个单独的服务器上以分散负载,以便有一个不同的服务器提供服务html,数据库和逻辑,并进一步做其他优化/缓存,以使hich是mvc应用程序规模并执行.
我认为即使在一个小的意大利面条应用程序中我们也不能有不同的服务器用于html,数据库等,我们可以通过在Web服务器,数据库服务器等之前使用负载均衡器来轻松扩展而不会降低性能.(假设它出现在这种情况下一台服务器还不够)
更重要的是它自己的意大利面条代码应该比mvc更好,因为它没有任何开销,如要求包含或文件或函数调用放在属于mvc的不同组件的文件夹下的文件.
那么,考虑到所有这些事情你真的认为将一个相对较小的意大利面条应用程序重构为mvc以实现可伸缩性和性能是有用的吗？
请不要告诉我,重构将来会有用(我知道这将有所帮助,并会考虑我们是否真的需要在现有代码库中添加更多代码)但是请给我一个明确的答案
1)我是否真的需要将此应用程序转换为mvc架构以实现可伸缩性和性能？
2)意大利面条应用可以像这样规模并且每天至少执行至少100万次请求,其中一半在某个高峰期发生吗？
据我所知,您可以将mvc的每个组件放在一个单独的服务器上以分散负载
我自己从来没有听说过 - 但是我来自一个.Net世界,你无论如何都要在同一台服务器上运行你所有的托管代码(这不像你在Java世界中经常有一个单独的"App"服务器和"网络服务器).
您可能转向MVC的主要原因(正如您所提到的)是管理代码的好处:关注点分离,重用等等; 没有表现.
从理论上讲,您可以使用基于对象/组件的技术(如Java或.Net)来实现这一点,其中组件相互通信 - 但是在过程代码中？我不这么认为!
那么,考虑到所有这些事情你真的认为将一个相对较小的意大利面条应用程序重构为mvc以实现可伸缩性和性能是有用的吗？
不 - 假设通过可扩展性和性能,您可以参考系统的运行时质量,我相信这就是您的意思.
如果您将可扩展性和性能完全放在开发环境中(人员编码 - 他们可以在系统上多快和轻松地工作,您可以轻松地将开发人员添加到项目中)那么答案就是肯定的.
2)意大利面条应用可以像这样规模并且每天至少执行至少100万次请求,其中一半在某个高峰期发生吗？
什么都不可能 - 我喜欢Gordons的评论 - 但是我相信你会同意,这可能不是你能做到的最好的基础.