@yashrajbothra @brady.miller I don’t mind if we go to Symfony 5, but Symfony 4.4 is the Long Term Stable release and it’d be my preference to stay on 4.4 until Symfony 5 has a Long Term Stable (LTS) release. Symfony 4.4 runs fine on PHP 7.4 we just would have to bump our OpenEMR PHP composer constraint to 7.4.
If we do upgrade to 5 the proposal work would need to go through and identify any deprecated constraints with the current symfony components and then upgrade them. Also we’d need to plan on making some quick upgrades every 4-5 months until the 5.X release hits the LTS release. (See this upgrade guide from Symfony for details: https://symfony.com/doc/current/setup/upgrade_major.html)
The goal behind services is to move all data layer and application logic out of the views and into cohesive classes. What you proposed of moving portions of the code into using an ORM with the help of doctrine and cleaning up of redundant assets is a good thing. I will mention that moving things into using Doctrine’s ORM will be more involved than you may think due to the fact that we have an AUDIT trail of every SQL change in the database. You’ll have to leverage some form of @PreUpdate or @PostUpdate metadata that your entity classes inherit from in order to maintain the audit trail. I believe @juggernautsei did some work on this at some point and can give you some guidance specifically with the Doctrine jobs.
I think going with what Brady said of taking a look at the Chart Tracker and what it would take to separate everything into a Model / View / Controller type structure with a thin Controller that uses Services for the majority of the application logic would be a good stab at this. Note that your goal will not be to convert the entire codebase as this is several, several man years, but taking something small and building on it from there.
I hope that helps.