Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.

I have a small SAS ERP that was written some years ago using PHP.

At that time, it didn't use any framework, but the code isn't a mess.

Nowadays, the project grows and I’m now working with 3 more programmers.

Often, they ask to me why we don’t migrate to a framework such as Laravel.

Although I'd love trying Laravel, I’m a small business and I don't have time nor money to stop and spend a whole year building everything from scratch. I need to live and pay the bills.

So, I've read a lot about this matter, and I decided that doing a refactoring is the best way to do it.

Also, I'm not so sure that a framework will make things easy.

Business goals are:

  • Make the code easier to new hired programmers

  • Separate the "view", in order to:

    • release different versions of this product (using the same code), but under different brands and websites at the minimum cost (just changing view)

    • release different versions to fit mobile/tablet.

  • Make different types of this product, selling packages as if they were plugins.

  • Develop custom packages for some costumers (like plugins/addon's that they can buy to put on the main application).

Code goals:

  • Introduce best pratices, standards for everyone

  • Try to build my own MVC structure

  • Improve validation of data/forms (today they are mixed in both ajax and classes)

  • Create automated testing routines for quality assurance.


My current structure project:

  • class\
  • extra\
  • hd\
  • logs\
  • public_html\
  • public_html\includes\
  • public_html\css|js|images\

class\

There are three types of classes.

They are all “autoloaded” with something similar with PSR-0, but I don’t use namespaces.

1. class.Something.php

Connects to Database using specific methods. I.e: Costumer->list();

It uses “class.Db.php”, that it’s an abstraction of mysql on every method.

2. class.SomethingProc.php

Do things that “join” things that come from “class.Something.php”. Like IF/ELSE, math operations.

3. class.SomethingHTML.php

The classes with “HTML” suffix implements only static methods and HTML code only.

A real life example:

All the programmers need to use $cSomething ($c to class) and $arrSomething (to array).

Costumer.php (view)

<?php
$cCosumter = new Costumer();
$arrCostumer = $cCostumer->list();
echo CostumerHTML::table($arrCostumer);
?>

Extra\

Store 3rdparty projects/classes from others, such MPDF, PHPMailer, etc.

Hd\

Store user’s files outsite wwwroot dir.

Logs\

Store phplogs and the system itself logs

(We have a static Log::error() method, that we put in every method of every class)

Public_html\

Stores the files that people use.

Public_html\includes\

Store the main “config.php” file and all files that do “ajax things” ajax.Costumer.php, for example.

Help is needed ;)

So, as you can see we have some standards, and also for database things.

But I want to write a manual of our rules. Something that I can give to any new programmer at my company and he can go on.

This is not totally a mess, but it could be better seeing the new practices.

What could I do to separate this as MVC, to have multiple views.

Could you give me some tips considering my goals? Keep im mind the different products/custom things for specific costumers without breaking the main application.

URL for tutorials, books, etc, would be nice.

share|improve this question
    
This is a very long and broad question. It could be summarized to e.g. "Best practices to refactor PHP project into MVC without introducing frameworks?". The full details of the project structure are not needed, but the code conventions used are indeed useful. Furthermore, you are aware that "Costumer" is spelled "Customer", right? –  logc Jun 10 at 9:47
    
@logc I'm not american. Sorry about "customer", but i did my best trying to write this in english. Yes, maybe. I put the structure to help others to gimme real life explantions how to migrate it to a framework, if it's the solution. –  b0x 2 days ago
    
I am also sorry if I sounded harsh. Just trying to help you. It is not always easy to convey that in a short comment :) –  logc 2 days ago
add comment

1 Answer

Since this is not a technically oriented question, I'll try my best to give you a perspective from a Laravel developer who refactored some old code just a couple years ago. Keep in mind that I don't have a real knowledge of your business nor your codebase to give you an accurate answer and most of what I say will be based on guesses and opinions.

Refactoring to a framework may seem ideal at first, specially because it will pay off in the long run, but only if you find yourself developing new features on that application often.

If this system is barely touched by developers and you don't have any perspective of customizing it on the following months, I would suggest you to stick with your approach that is working right now.

Although I only have good things to say about Laravel, it takes sometime to learn and get used to it, and even more time to refactor such a core system of your business, as with any other framework.

Ideally, you should only take that path if your other developers have previously worked on a couple Laravel projects. Otherwise they will struggle in the beginning and you may spend more time trying to find your way through new methodologies and complexities than really working on refactoring.

If you do decide to refactor your code, you should try doing it by parts. Laravel (v4) is mainly composed of independent modules which work on their own and may be included through composer on your projects alone.

The first step is to separate all your real logic from html markup. You could achieve this by simply creating classes and functions that return the necessary data to render any html. This is crucial to implement MVC on any application.

Then you should go for a routing mechanism to handle requests, controllers to organize each request logic and only then you should go for models and refactoring your core codebase (your business centered logic).

My suggestion:

From a pure business perspective, you should write automated tests before such a change. Not only it will help ensuring your site is running smoothly, they also allow you to refactor your code much faster. Tests increase productivity as much or even more than frameworks.

I suggest you to start with behavior tests and some headless browser. You can use codeception, behat and many other alternatives for that.

share|improve this answer
    
Hi vFragosop thanks for your answes. This is the main project here and we touch it everyday. I will follow your steps, but first i need to study Laravel, to understand it and try to "copy" behavior to my own thing. –  b0x 2 days ago
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.