组织此项目的“正确方法”是什么？

Question

I'm working on a project that allows multiple users to submit large data files and perform operations on them. The "backend" which performs these operations is written in Perl while the "frontend" uses PHP to load HTML template files and determines which content to deliver. Data is stored in a database (MySQL, SQLite, Oracle) and while there is data which has not yet been acted upon, Perl adds it to a running queue which delivers data to other threads based on system load. In addition, there may be pre- and post-processing of the data before and after the main Perl script operates (the specifications are unclear) so I may want to allow these processors to be user-selectable plugins. I had been writing this project in a more procedural fashion but I am quickly realizing the benefit of separating concerns as to limit the scope one change has on the rest of the project.

I'm quite unexperienced with design patterns and am curious what the best way to proceed is. I've heard MVC thrown around quite a bit but I am unsure of how to apply it. Specifically, what are some good options to structure this code (in terms of design patterns and folder hierarchy)? How can I achieve this with both PHP and Perl while minimizing duplicated code between languages? Should I keep my PHP files in the top level so I don't have ugly paths in the URL?

Also, if I want to provide interchangeable databases, does each table need its own DAO implementation?

Answer 1

This is really several questions, but here goes:

MVC

To implement MVC you'll need to have a clear idea of what the Model, View and Controller sections are responsible for. You can read about this for yourself , but in this case:

• The model should only contain the code which performs operations on the data files, ie the back-end Perl scripts
• The view will be the HTML templates only. No PHP logic should be embedded in them except what's necessary to display the page.
• The controller will be the rest of the application: the parts that connect the PHP front-end to the Perl back-end, and possibly the Perl scripts that poll for new files.

For every php, html or perl file you create, it should be absolutely clear to which section it belongs, in its entirety. Never mix up model, view or controller code in the same file.

There should be no reason why you can't continue writing procedurally. You don't necessarily need a framework either; It may help you to slot things into place, but may also take some time to learn.

MVC is a more of a separation of concerns that you need to keep in mind. A good way to think about it is: "Can each of these components work separately from the others", eg:

• can you write a 'mocked up' (example) data file, and have the Perl scripts process it without running any of the PHP code?
• can you request an operation from the front-end, and have it deliver all the parameters to a single place, ready for a single Perl routine to pick up, without running and Perl code?

You shouldn't need to worry about code duplication if the PHP and Perl scripts are doing totally different things (PHP is only setting up users parameters and input files, and Perl is only taking those parameters and files, and outputting new files).

As for folder hierarchy, if you're not using any existing framework, the most important thing is just that it makes sense, is consistent, and that you document your decisions, eg in a readme file.

Ugly URLs

You don't need to put your php files in any particular place. Use Apache rewrite rules to make the URLs pretty afterwards. ( rewrite rules generator - see the "301 Redirect File" section). But a good MVC framework will solve this for you.

User-selectable plugins

Be careful not to optimise too early. You may be able to develop the new pre/post-processing steps yourself, and just put them in a list for users to select from.

Answer 2

MVC frameworks are a great tool, for any web developer, that provides well-defined separation indispensable for keeping your code organized.

For PHP I recommend Zend Framework

Database schema will change depending on what platform you use.