Design Pattern for Data Processing? (MVC alternative)

Question

As a PHP/Web Developer, I'm a huge fan of MVC (Model-View-Controller). I love building an app on a solid foundation which definitely separates business logic, presentation logic, and flow of control.

However, I do a lot of work as well on server-side-only apps, which merely process data and log the process and any relevant results (such as import scripts, data migration scripts, web services, TCP socket servers, etc). There is no need for a big fancy MVC framework in these cases.

I realize that MVC can still be applied here, but it seems like overkill. Besides a raw procedural approach or a random mash-up of class objects, are there any specific Architectural Design Patterns out there especially suited to data-processing, run-once, and server daemon type applications?

Answer 1

I guess you need to start by asking yourself what's the problem you want to solve (with these patterns you're looking for)

Once you know this, you might find something useful here:

http://martinfowler.com/eaaCatalog/

Answer 2

I suggest you read this article first Introduction to Design Patterns Using PHP

This would then help you understand and choose a Pattern from this page. Design pattern

Answer 3

Since it is data processing related, I assume that you have some kind of data store, you can look at Repository and DTO (Data Transfer Object) architectural patterns.

More generically, some of the design patterns in GoF catalogue will also suit you such as Singleton for run-once, Facade for abstracting the processing logic, Strategy for different processing logic, State Machine maybe for the daemon

Answer 4

If I understand correctly, the applications you're talking about don't have a user interface beyond the shell command line. If that's the case, you can still use MVC at the software architecture level - your View will simply be trivial. Your Controller will similarly be trivial, since there are very few actions to propagate between the Model and the View.

Of course, with a trivial View and Controller it might as well not be any pattern at all. I don't see an issue with that (at the level you're talking about). The key is to take an interface-based approach (much as you would with MVC) and this will tend to give a better design in the end; one which may easily be adapted to a different user interface or means of invocation if required in the future.