SitePoint Sponsor

User Tag List

Results 1 to 15 of 15
  1. #1
    SitePoint Enthusiast
    Join Date
    Jan 2005
    Location
    UK
    Posts
    66
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)

    Converting an existing PHP application on to a framework

    A couple of years ago I developed an online shop & content management system from scratch. It doesn't use any kind of framework like symfony, cakephp, etc - it never really occurred to me at the time.

    Now I having an argument with myself over whether I should continue the development of the application or bin it and start again but using a framework. There a several thoughts against starting again and to be honest, am finding it hard to justify the amount of work that might be required to do this.

    The application has 275 files is split into sections (products, menu, checkout_details, etc). Each area is made up of several files - e.g. for the menu section:

    • list_file - shows all the menu items in each menu
    • action_file - does the processing for each item (create, update, delete)
    • menu_file - displays the form (and for edit function, gets the current data)
    • form_file - the html form
    • functions_file - contains the functions for the menu area's operations

    There is a core includes directory which contains all the general functions, config information, etc - everything that is used in lots of places. Another directory contains all the thirdparty plugins such as TinyMCE, etc.

    Something that weights the argument against rebuilding is that the likes of vBulletin isn't built on any of the frameworks (or at least doesn't look like it anyway).

    I would be really interested in hearing anyones opinions on whether moving an existing application over to a MVC framework is worth it.
    Design is an art... Then someone releases a new browser...

    Farstate Applications

  2. #2
    SitePoint Wizard
    Join Date
    Mar 2002
    Location
    Bristol, UK
    Posts
    2,240
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    If it ain't broke, don't fix it

  3. #3
    SitePoint Addict joaquin_win's Avatar
    Join Date
    Jul 2005
    Location
    Venezuela
    Posts
    224
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Unless you're feeling that your architecture is not allowing you to get things done quickly or it's really broken then it doesn't make sense.

    Like SJH said, If it ain't broke, don't fix it

  4. #4
    SitePoint Addict
    Join Date
    Nov 2005
    Location
    Germany
    Posts
    235
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by Emj View Post
    I would be really interested in hearing anyones opinions on whether moving an existing application over to a MVC framework is worth it.
    If you expect to extend and develop this application massively in the future moving to a framework might be worth your time. Adding features will be easier in a consistent environment where you don't have to deal with architectural tasks - a good framework lets you concentrate on your business logic.

    On the other hand if the application is running fine and you have no trouble with it why bother? I guess moving from no/little architecture to MVC is very close to a rewrite from scratch.
    Last edited by FrlB; May 19, 2009 at 09:15. Reason: typo

  5. #5
    SitePoint Addict Mastodont's Avatar
    Join Date
    Mar 2007
    Location
    Czech Republic
    Posts
    375
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    If the application code is good, you could also think about not converting on, but INTO (new) framework

  6. #6
    SitePoint Evangelist
    Join Date
    Aug 2005
    Location
    Winnipeg
    Posts
    498
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Start refactoring my friend...ignore the "If it ain't broke don't fix it".

    Software is always broke, and can always use improving.
    The only constant in software is change itself

  7. #7
    SitePoint Wizard
    Join Date
    Mar 2002
    Location
    Bristol, UK
    Posts
    2,240
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by PCSpectra View Post
    Software is always broke, and can always use improving.
    I think unless you're experiencing serious performance problems you should leave the architecture alone and concentrate on adding cool new features to the software. Much better use of your time IMO

  8. #8
    SitePoint Addict webaddictz's Avatar
    Join Date
    Feb 2006
    Location
    Netherlands
    Posts
    295
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by SJH View Post
    I think unless you're experiencing serious performance problems you should leave the architecture alone and concentrate on adding cool new features to the software. Much better use of your time IMO
    That's until the time it takes to write those "cool new features" takes up more time than it would in a more structured architecture. I am somewhere in the middle of the opinions above, and I think the only answer I can give you is: you tell us! This question can not be answered without more information on what the planning for the application is, how much time you have to spend to write new features.

    Just make a list of pro's and con's and estimate the time it'll take you before you make the decision. I myself have refactored legacy (vanilla) applications into a decent architecture, but there are also a few legacy applications I didn't touch, because there are no new requirements (for now). If the customer wants additional features, I'll see if I can implement them into the old codebase easily, if not, I'll do an estimate of how much time it would take to refactor and tell my boss it can't go on like this much longer.

    This brings me to the following point: are you developing this application for a client? If so; how is to pay for the refactoring? I tend to say that I, myself, am responsible for messing up a bit $i years ago, so I tend to not charge the customer for such changes. Then again, refactoring the apps doesn't usually take up a hell of a lot of time.

    For the people that say: "If it ain't broke, don't fix it", you should review the definition of "broke". In my book, software that can't be altered or extended rapidly, easily and in a structured manner is broken, even though it works for the customer.
    Yes, I blog, too.

  9. #9
    SitePoint Enthusiast
    Join Date
    Jan 2005
    Location
    UK
    Posts
    66
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Thanks for all the feedback so quickly!

    Quote Originally Posted by webaddictz View Post
    I am somewhere in the middle of the opinions above, and I think the only answer I can give you is: you tell us!
    Quote Originally Posted by SJH
    I think unless you're experiencing serious performance problems you should leave the architecture alone and concentrate on adding cool new features to the software.
    The current application is fully modular in that each section (products, menus, customers, orders, etc) is independent from eachother. All sections share a common functions library which is included in each file. The functions library contains things like string, file, database functions, etc that are not specific to any particular area.

    The design side of the application (html/css) is in seperate template files, so changing the css class of some text throughout the application (i.e. renaming the class) is only a matter of going to a single place in the core template or library.

    Quote Originally Posted by webaddictz View Post
    This brings me to the following point: are you developing this application for a client?
    Yes and no. The application is in use by a number of clients all of whom (from time to time) feedback wibni's, etc. These are all considered on a case by case basis and if deemed to be of use by many clients, are then implemented.

    Quote Originally Posted by Mastodont
    If the application code is good, you could also think about not converting on, but INTO (new) framework
    I spent some time thinking about this after you mentioned it, and perhaps the application is actually not that far from being a framework. If an application meets these conditions:

    1. Design/layout can be changed without modifying every file (i.e. can be changed centrally)
    2. Processing is separate from display/operation
    3. Commonly used code blocks are available as functions to all parts of the application (i.e. are stored centrally and not repeated)

    Performance wise, the application does not seem to suffer - there have never been any reports of poor performance, nor has monitoring/error logging shown there to be poor performance.

    I am not sure how many of the PHP frameworks (other than Zend) were around 2 years ago when I first created this application, I don't really remember being aware of any although it could have just been a case of not looking hard enough. I think if I was building the application now, then a framework is the way to go - I have probably re-invented the wheel a number of times which wouldn't have been neccessary with a framework.

    Thanks for all the comments - all very welcome, and if anyone wants to add anything, please feel free! Might help others also thinking about this.
    Design is an art... Then someone releases a new browser...

    Farstate Applications

  10. #10
    SitePoint Addict
    Join Date
    Nov 2005
    Location
    Germany
    Posts
    235
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by Emj View Post
    I spent some time thinking about this after you mentioned it, and perhaps the application is actually not that far from being a framework. If an application meets these conditions:

    1. Design/layout can be changed without modifying every file (i.e. can be changed centrally)
    2. Processing is separate from display/operation
    3. Commonly used code blocks are available as functions to all parts of the application (i.e. are stored centrally and not repeated)
    These conditions do not define a framework, rather a decoupled application. Now an application framework (with architecture) is not an end in itself, it is primarily there to decouple parts (layers, modules) of the application. If the application is in a sufficiently decoupled state (e.g. meeting your conditions) there's no need to introduce a framework.

  11. #11
    SitePoint Wizard silver trophy kyberfabrikken's Avatar
    Join Date
    Jun 2004
    Location
    Copenhagen, Denmark
    Posts
    6,157
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by FrlB View Post
    If the application is in a sufficiently decoupled state (e.g. meeting your conditions) there's no need to introduce a framework.
    I think it makes sense to say that there are at least two very different aims of a framework. The first is to support the quality of applications written to it. That's what you're talking about here. The other is to standardise the application so as to make it easier to integrate it with other software that follows the same standard (or other developers who knows the standard). Anyone choosing a framework must weigh these goals, since they are - at least to some extend - in conflict with each other.

  12. #12
    SitePoint Addict
    Join Date
    Nov 2005
    Location
    Germany
    Posts
    235
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by kyberfabrikken View Post
    I think it makes sense to say that there are at least two very different aims of a framework. The first is to support the quality of applications written to it. That's what you're talking about here. The other is to standardise the application so as to make it easier to integrate it with other software that follows the same standard (or other developers who knows the standard).
    Is the integration with other software really something that is influenced by the use of a framework? Can you give an example? (I'm surprised to see this aim ranked so highly - in my opinion the second important goal achieved with a framework is increased development speed.)

  13. #13
    SitePoint Addict
    Join Date
    Feb 2007
    Posts
    270
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    If it ain't broke, don't fix it
    I prefer the Tom Peters version: "If it ain't broke, you ain't looked!"

    Grab an MVC framework and learn how it works, first, then make your decision. While you're learning it, that wonderful pattern-matching engine you carry between your ears will be busy in the background trying to make the pieces of your old app fit into the new mold, and it'll let you know if it likes what it finds.

    But your job as a developer is to wrap your head around as many different approaches to solving a problem as you can. So grab that framework and learn it. Even if you decide not to use it, your coding will only improve from the experience.

  14. #14
    SitePoint Wizard silver trophy kyberfabrikken's Avatar
    Join Date
    Jun 2004
    Location
    Copenhagen, Denmark
    Posts
    6,157
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by FrlB View Post
    I'm surprised to see this aim ranked so highly
    Oh, I certainly didn't assert their individual importance. I'm just identifying them as two separate goals.

    Quote Originally Posted by FrlB View Post
    Is the integration with other software really something that is influenced by the use of a framework? Can you give an example?
    Integration may happen on the people level (If you know the language/framework already, you are more likely to be able to work with it right away) or at the systems level (Plugins and other code-reuse).

    Quote Originally Posted by FrlB View Post
    in my opinion the second important goal achieved with a framework is increased development speed
    How do you measure development speed? Time taken to implement trivial features? Time taken to implement complex features? By a developer who knows the framework or by one who doesn't?

  15. #15
    SitePoint Addict
    Join Date
    Nov 2005
    Location
    Germany
    Posts
    235
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by kyberfabrikken View Post
    How do you measure development speed? Time taken to implement trivial features? Time taken to implement complex features? By a developer who knows the framework or by one who doesn't?
    I would suggest to measure the time taken to implement a non-trivial standard feature. That should be good enough. In case of high initial costs to set up the FW they can to be taken into account as well. The developer (team) knows the framework.
    The effect I saw when using frameworks (homegrown or third party, PHP and Java) is that the amount of code to write, test and maintain is far lower. But to be honest, most projects I've seen or worked on where those standard CRUD beats, where complexity comes mostly from size and is not inherent. And I just boldly assume the FW fits the task. Having really fancy requirements where you have to tinker at and maybe cross the boundaries of a FW you might be better off without. But I don't think this is a standard case.


Bookmarks

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •