Doing so should reduce the occurrence of new bugs significantly because of better walling off of functions within layers, and the contributions of many developers to the ongoing development and improvement of these components.
Some suggestions:
Doctrine ORM for database abstraction layer instead of custom.
Symfony for PHP application framework instead of custom.
JQuery for front end ajax javascript user interface from Yahoo YUI.
Twig from Smarty template engine.
Hi ChrisC,
You cant just migrate sugars core architecture to a different framework like Symfony you would have to rewrite it.
What your suggesting is to build a completely new CRM more or less from the ground up! It would no longer have anything to do with sugarcrm.
It would be a huge undertaking to do that.
Hi Andy,
Agreed, it would take some huge amount of refactoring work to migrate to Doctrine ORM as the database layer, remove all the MySQL assumptions, and get all the hardcoded SQL strings out of the code.
The thing that would make it not so terribly bad of an undertaking is how Sugar 6.5 and Suite 7 do actually use a separate database layer that’s replaceable. It’s how Sugar 6.5 is able to support PostgreSQL, Microsoft SQL Server, Oracle, and IBM DB2.
So adding Doctrine ORM would probably be a couple of weeks of refactoring with a couple of people - in my opinion.
One great thing about Doctrine is there’s no need whatsoever to write XML description of the database. It’s able to read an existing database and generate the XML needed to run its engine. The time saved is massive.
It would be good to use an ORM but I cant see us going down that route any time soon.