Perl and Ruby on Rails were also evaluated as possible options to solve our business needs. ASP.NET is, of course, more expensive, but provided a robust and somewhat easier integration of the specific tool-set required to provide excellent service to our customers. The …
Well suited: for interfaces between machines data and applications. Made as a service. For web applications in factories where you don't have access to thick clients due to the environment. not well suited: quick measurements and fast data transitions between different applications. When time dependency is needed, then you better can choose other solutions.
If you need to create simple CRUD applications using a MVC framework, I could say CakePHP could achieve this. But with frameworks like Laravel on the market, I would have a hard time recommending CakePHP for anything.
The biggest issue inherit in CakePHP, and why we switched to Laravel, is the base configuration of the program. Most people aree that CakePHP uses old (outdated, even dangerous) PHP habits. There is some truth in this: Cake has not been as quick to adapt to the newer PHP versions as they should. I was always surprised that with new major releases, from 2.4 to 2.5 for example, that the minimum version of PHP will never increase. For example, CakePHP only requires version 5.2.8 of PHP, but it would not have been difficult to update the minimum version at least 5.3 when adapting a new version.
Speed - our company had many issues scaling CakePHP to a medium size application software, even with using REDIS/memcache we would still run into many issues with the built-in ORM.
We choose ASP.NET because our core business is working with the SAP HANA database using SAP Business One. We can develop state-of-the-art applications with Razor and Visual Studio 2022 fast and with excellent application performance response. Working SAP Hana with JAVA could be more challenging because it has fewer developers communities, and it could be harder to find a solution for a question.
