我有一个
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万次请求,其中一半是在某个高峰时间内发生的吗?