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?
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.
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/
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
Related
Does MVC really means you have to separate => View aka design (html css) => controler (php code), model (mysql code into classes etc.)???
Are there not alternatives? Wondering because I would really like to avoid separating php code and mysqli as right now it's sooo easy to work on it (got used to it).
Yes, you definitely want to separate HTML and CSS from business logic.
Most frameworks use an ORM or something similar to abstract building queries but still give you the option to write plain SQL. I would recommend to use an ORM like doctrine2 for example over plain SQL. If you use any SQL directly the model would most likely the right place to put it into.
MVC exists for a reason, separation of concerns. This makes sure that your application becomes easy to maintain because every part of it should be easy to replace and not depend on each other to much. You want to avoid strong coupling. MVC is a pattern that helps you with that.
And like tttpapi said, there other ways to do it, but honestly, I personally think that specially Wordpress for example is a horrible clutter. I don't like Drupal or Joomla as well. The code base feels like working with 10 year old clutter compared to a modern well written application following the MVC pattern.
This is a little about discipline es well, I've seen totally messed up applications as well because people did not pay attention to separation of concerns and didn't follow the MVC pattern.
Does MVC really means you have to separate => View aka design (html
css) => controler (php code), model (mysql code into classes etc.)???
No.
MVC is about separation pf concerns. It separates presentation layer from model layer. And within presentation layer - it separates handling of input (controllers) from handling of output (views).
The model in MVC is not a databases abstraction or collection of queries. Instead it is a layer that contains several groups of classes. The major groups are domain objects, data mappers and services. The model in MVC is all these things taken together.
Longer explanation: here
Note: do not confuse MVC's model with domain model, which is the accumulated knowledge and vocabulary for specifica application. The part of domain model, that can be encompassed in code, is implemented using domain objects.
View is not html and css. Views in MVC are classes that contain the UI logic for the application. THey acquire data from model layer and then, based in this information, choose which templates to use for producing a response.
Longer explanation: here
Controllers are not some mystical "php code". They are part of application that takes user input, and based on that alter the state of model layer and (in rare cases) state of current view.
Are there not alternatives? Wondering because I would really like to
avoid separating php code and mysqli as right now it's sooo easy to
work on it (got used to it).
The point is NOT separating SQL from PHP.
The separation of concerns principle simply means that each part of your application should be dealing with one specific aspect.
And, if you try to implement MVC architecture, it will NOT mean that you separate sql from php, but that you separate business logic from persistence logic. Both of those would be written in PHP. But the trick is - MySQL is not the only form of storage. Data can also be stored in session, in cache, in noSQL, in files, in SOAP, etc. If you have separated business logic from persistence logic, then you can add caching to your existing application without rewriting the whole thing.
Also ...
There are more architectures then just MVC and Big Ball of Mud (which was advertised by people who talked about Drupal and Joomla).
You have MVP, MVVM, n-Tier, DCI, EDA and many others. And all these will be adhering to SoC principle .. but the result that they come up with will be different.
P.S.: If you actually want to learn about MVC, I would recommend for you to start going through materials from this list. It will start by introduction to simple concepts and gradually build up to ideas that you have to grasp to actually start working with MVC.
It is always up to you.
You always can find way how to use MVC as nonMVC. (example is Joomla here you can use just view with all code in it)
Or you can use systems that are not MVC bases such as Drupal.
But the MVC is here for some reasons.
To directly answer your question, yes MVC means exactly that.
However MVC is just a design pattern, and not a holy writ.
There are many variations available to you. I myself initially thought MVC to be restrictive and confusing, but in fact it was the particular MVC based framework i choose that had these failings.
There are many lightweight, flexable frameworks available. Take a look at https://github.com/bcosca/fatfree as a nice example, in particular the database section. You wont think mysqli is simple in comparison
I was asked to do a project in PHP and to make sure it was object oriented. I've done OO and I've done PHP, but never both.
The main benefit of OO PHP (outside of inheritance/polymorphism) seems to be code organization. That's fine; I'm doing that. But where I get stuck is if I should actually be creating instances for every "object."
To me (and maybe I'm being naive here), a web app is all about making very short, stateless requests to alter or retrieve records in a database. The objects can't persist between requests. So it feels rather pointless to load data from the database, construct an object from that data, make a small update, save the data from the object back to the database, and then throw the object away. The loading/saving code seems to be a lot of work for nothing. [clarification: a waste of development time, not processing time... not too concerned about overhead]
The alternative is to have a bunch of singletons (or classes with static methods) that just provide a nice, organized abstraction layer to the database layer. I guess writing code in this manner just doesn't feel truly OO. Am I missing something or is that style fine?
Yes, you could summarise the benefits of OO as "code organization"; but this is true for all languages (not just PHP). In reality, it's more than that; it's about how you think about your data structures and algorithms, i.e. about how they map to concepts in the problem domain, how they relate to one another (ownership, parent-child, polymorphism, etc.), and how they expose clean, consistent interfaces to one another (encapsulation). If these concepts would benefit your application, and outweigh the extra development time vs. a quick-and-hacky procedural solution, then go for it.
I don't think persistence has anything to do with it.
I think you should question why you've been asked "to make sure it was OO". This seems like a pretty arbitrary request without further justification. Normally, the approach should be to write your application in the style that best suits the requirements, not arbitrary whims...
Singletons are essentially just global variables with some namespace sugar added in. There are a few main benefits to programming with objects and classes that you just don't get from straight procedural programming. One is inheritance, as you mentioned. Another is the namespacing - you can have a code to compress the lot into a single include file (more meaningful in interpreted languages like PHP than in compiled languages).
Objects are essentially a collection of functions with a shared state (though singletons make that a global state. Beware.) As you pointed out the benefit is mostly that that state is transparently shared by the functions without needing to explicitly pass it every single call. If you have various functions per request operating on shared data and wish them to be specialized forms of a general set of functions, OOP is probably a good fit.
Since you have been tasked to "make sure it is object oriented", I'd take some time to consider common groups of functions, generalizations of same, etc.
In the end the setup/teardown time of the objects isn't too bad - and it might even save some development time in the future if you do a good job.
I think OOP is just a programming style and has nothing to do with developing an application. What you need is a pattern that provides a sufficient abstraction layer (for example: MVC).
My recommendation is: Fat-Free.
It's tiny, simple and quickly take you to the minimal viable version of your product. It has everything that you might need (Caching, ORM, CRUD, Captcha...) and is so flexible that you can use any pattern and with your custom directories hierarchy.
Check out the extensive documentation. The only issue is that it requires PHP 5.3. I think it's reasonable considering the options and flexibility it offers. It really changes the way you work; you should definitively give it a shot.
Like most things in life answer is somewhere in a middle.
Todays application use ORMs (for example doctrine for php) for different kind of optimization, better understanding of database approach (which is important for larger dev teams), easier update of the code, abbstraction layer that is well known to people who join the project, caching mechanisms,....
Classes with static methods are just fine if you are doing some smaller project on your own, but when more people are involved in progress you simply need something more robust and standardized.
I have asked a similar question before and got an convincing answer as well?
What is difference of developing a website in MVC and 3-Tier or N-tier architecture?
Due to the conclusion of this question I started developing projects in N-tier Architecture.
Just about an hour ago, I asked another question, about what is the best design pattern to create interface? There the most voted answer is suggesting me to use MVC architecture.
What is the best design pattern to design the interface of an WebPage?
Now I am confused, First post suggested me that both are similar, just a difference that in N-tier, the tier are physically and logically separated and one layer has access to the one above and below it but not all the layers.
I think ASP.net used 3 Tier architecture while developing applications or Web applications. Where as frameworks like Zend, Symphony they use MVC.
I just want to stick to a pattern that is best suitable for WebProject Development? May be this is a very silly confusion? But if someone could clear this confusion, that would be very greatful?
They aren't mutually exclusive. The Model-View-Controller pattern is really a user interface design pattern, and it concerns logical rather than physical tiers.
I most often hear "n-tier architecture" used to describe the actual physical separation of an application's layers. For example, a system in which the user interface runs in one process, exchanges data with an application layer (perhaps via messaging or web services) that executes in another process (perhaps on another server), which in turn accesses a data layer that runs in yet another process (typically a database server).
This description can be particularly confusing because 'application logic' can mean multiple things: in an n-tier system it usually means business logic - as opposed to user interface logic (like which widgets are enabled when the user selects a particular checkbox).
For example, in an n-tier system, your presentation layer might call a web service method that accepts an item ID. The web service runs on a different server, where it performs complicated calculations and returns a price.
In a simpler architecture, your application might calculate the item's price in the same process as the user interface - though the pricing logic may be separated into its own logical layer (perhaps within library or executable).
I can't think of any current MVC frameworks that care whether their layers run in separate physical processes or not.
I just want to stick to a pattern that
is best suitable for WebProject
Development? May be this is a very
silly confusion? But if someone could
clear this confusion, that would be
very greatful?
I think your confusion lies in two areas:
1) The assumption that there's one solution for every problem.
The requirement of your project will dictate which solution is best.
2) The definition of MVC when applied to the web is different than when it originally applied to desktop applications.
Some folks say that if the view doesn't talk to the model, then it can't be MVC. Well, most of the web MVC implementations don't have the view talk to the model, yet it's still called MVC.
Since you are a self-described amateur, you should embrace this one axiom early on: the programming world is confusing to everyone all the time.
You may want to review the Microsoft Application Architecture Guide. It has a good overview of the available Microsoft technologies from an Architecture standpoint. Chapters that might be of interest to you:
Chp 21 Designing Web Applications
Appendix B: Presentation Technology Matrix
Appendix C: Data Access Technology Matrix
As for what is best? You have to answer that yourself. Make some sample projects using MVC, WebForms, etc.
Web-based MVC is much different than the traditional desktop MVC. The Model simply has no way to update the View, because the web is (for the most part) stateless.
Even if you used AJAX to poll the server every couple seconds to check for Model updates, that still wouldn't be "true" MVC because it's not the Model notifying the View, it's the controller constantly "querying" the Models.
The lesson learned is that it really doesn't matter what you label your architecture. There are just so many variants of MVC/3 tier that usually people just lump them under the "MVC" blanket. And all of these are suitable for web development. I just can't think of any practical way to have the Model actually notify the View through server-side programming (at least not in PHP). If you need this kind of behavior, you should be writing a desktop application. Just write what is natural for you and don't get caught up in terminology debates. Look at what some of the well known frameworks like CodeIgniter, Kohana, Symfony, CakePHP, and Zend do and pick and choose which features or design patterns you like.
Why not use both?
At the moment I'm busy developing a project using the MVP pattern and in an N-tier architecture.
I'm using the MVP pattern in the user interface project, ie. the website. All the data which needs to be shown and used in the website is passed from a webservice. This webservice is connected to a business layer (BLL), which is connected to the data access layer (DAL). The DAL is connected to the database using the Entity Framework.
So in this project I'm using them both. Using MVP instead of MVC though.
This way the interface project (website) doesn't has to do hard stuff, only pass through some data which is received from the webservice. Took me a while to set up, but it works quite wonderfull.
Also, there is no real answer to which pattern or architecture is the best. It all depends on what you want and need. If you want to be scalable, an n-tier architecture is a good solution. If you want to be able to test your UI quite easily, an MVC pattern is good also. There's a ton of other patterns and architectures which would suffice as well, as long as you know how to use them.
There is no which is better. MVC and n-tier are not either or things. One is object/API design, one is system architecture. The question to distinguish between the two has been asked and answered here:
MVC Vs n-tier architecture
I'm going to write a framework for my web projects in PHP.
Please don't tell me about considering to use some existing framework (Cake, CodeIgniter, Symfony, etc.) - I have already had a look at them and decided to write one for myself.
The framework itself will mainly consist of a module system, a database handler and a template parser. (Many other things too, of course)
With module system I mean that every module has exactly one PHP file and one or more templates associated with it.
An example module would be modules/login.php that uses templates/login.tpl for its design.
These days everyone(?) is talking about the MVC (Model View Controller) concept and most of the existing frameworks use it, too.
So my questions are the following:
Is MVC really effective for a personal framework?
Would it be a bad idea to use a module system?
Did you ever write a framework for yourself? What are your experiences?
Is MVC really effective for a personal framework?
Yes, it can be. Although, it might be a little overkill (which, is not necessarily a bad thing if you are trying to learn)
Would it be a bad idea to use a module system?
This is never a bad idea.
Did you ever write a framework for yourself? What are your experiences?
I wrote a common security framework for my group's PHP applications when I was an intern. I learned alot, but the project as a whole might have benefited more from a pre-built solution.
Of course, I wouldn't have learned as much if I just installed a pre-built solution. So you always have to take that into account, especially for personal projects. Sometimes re-inventing the wheel is the only way you will learn something well.
Is MVC really effective for a personal framework?
What MVC means anymore, due to its vague interpretation, is business logic, presentation, and input handling. So, unless you aim to design an application that does not involve any three of those, MVC is, in its vague sense, very suitable.
Often it can be more formal than you desire, however, as it demands physical separation of ideas into different code files. Quick and dirty tasks or rapid prototyping might be more quickly setup if the formalities are avoided.
In the long term, what MVC asks for is beneficial to the sustainability of the application in ways of maintenance and modification or addition. You will not want to miss this. Not all frameworks encourage the right practices, though. I am not surprised that you find the various implementations you've tried insufficient. My personal favourite is Agavi. To me and others, in a world of PHP frameworks that do not feel right, Agavi emerges to do the right things. Agavi is worth the shot.
Would it be a bad idea to use a module system?
MVC asks you to separate components of business logic, presentation, and input handling, but it does not suggest how to layout the files. I presume this is the challenge you are addressing with a module system. To answer your question: modules serve identically to sub-directories. If the items are few, its probably more hassle to bother with subdirectories even if the files could logically be separated into them. When the number of items grow large, its now cumbersome to locate them all and sub-directories become a better option.
Frameworks will tack on functionality that allows you to deal with modules as their own configurable entity. The same functionality could just as well exist without modules, perhaps in a more cumbersome manor. Nonetheless, do not consider modules primarily as a system. Systems are so wonderfully vague that you can adapt them to whatever setup you find suitable.
Did you ever write a framework for yourself? What are your experiences?
Yes I have wrote several frameworks with various approaches to solving the issues of web applications. Every such framework I wrote became nothing but a vital learning curve. In each framework I made I discovered more and more the issues with building software. After failing to create anything interesting, I still gained because when asked to make a program I could fully do so with justice.
I recommend you continue if this is the sort of learning experience you want. Otherwise, give Agavi a shot. If that too fails, ensure that you have a clear and detailed specification of what your framework will do. The easiest way to barge into making software, work really hard, and accomplish nothing is to not decide before-hand what exactly your software will do. Every time I ran into making code the only thing in my mind was I will do it right. What happened was a different story: oh, well I need to make a routing system as that seems logical; hmm, okay, now I need a good templating system; alright, now time for the database abstraction; but gee, what a lot of thinking; I should look to the same system from software XXY for inspiration. Therein is the common cry that pleads to use existing software first.
The reason I thought I could do it right was not because all the nuts and bolts of the framework felt wrong. In fact, I knew nothing about how right or wrong they were because I never worked with them. What I did work with was the enamel, and it felt wonky. The quickest way to derive your own framework is really to steal the nuts and bolts from another and design your own enamel. That is what you see when building an application and frankly is the only part that matters. Everything else is a waste of your time in boilerplate. For learning how to build software, however, its not a waste of time.
If you have any other questions, please ask. I am happy to answer with my own experience.
I am also actually writing a php framework with a friend of mine. I absolutely can understand what you do.
I thing what you are doing is near mvc. You have the templates as views. And the modules as controller. So I think that is ok. The only thing you need is the model. That would be some kind of active records.
In my framework there are simular concepts, except we are writing our own active records engine at the moment. I think what you do isn't bad. But it's hard to say without seeing code.
I see only one problem you have to solve. A framework should be perfectly integrated. It is always a complicated to make your module look nice integrated without always have to think of module while you are coding application.
Is MVC really effective for a personal framework?
Would it be a bad idea to use a module system?
Yes it is. But MVC is such a loosy-goosy design pattern that you can draw the line between model, view, and controller anywhere you want. To me, the most important parts are the model and the view. I simply have pages, php modules, that generate html by filling in a template from a database. The pages are the view and the database is the model. Any common application-specific code can be factored out into "controllers". An example might be a common, sophisticated query that multiple pages must use to render data.
Other than that I have utilities for safe database access, simple templating, and other stuff.
Did you ever write a framework for yourself? What are your experiences?
Yes. I'm very glad I did. I can keep it simple. I know intimately how it works. I'm not dependent on anyone but myself. I can keep it simple yet useful.
Some pointers (0x912abe25...):
Every abstraction comes with a cost.
Don't get to fancy. You might regret not keeping it simple. Add just the right amount of abstraction. You may find you over-abstracted and something that should be simple became excessively complex. I know I've made this mistake. Remember You-aint-gonna-need-it.
Scope your variables well
Don't load your pages by doing
include_once('...page file ...');
where it's expected that page file will have a bunch of inline php to execute looking up different global variables. You lose all sense of scope. This can get nasty if you load your page file from inside a function:
function processCredentials()
{
if (credentialsFail)
{
include_once('loginpage.php');
}
}
Additionally, when it comes to scoping, treat anything plugged into templates as variables with scope. Be careful if you fill in templates from something outside the page file associated with that template (like a master index.php or something). When you do this it's not clear exactly what's filled in for you and what you are required to plug into the template.
Don't over-model your database with OO.
For simple access to the database, create useful abstractions. This could be something as simple as fetching a row into an object by a primary index.
For more complex queries, don't shy away from SQL. Use simple abstractions to guarantee sanitization and validation of your inputs. Don't get too crazy with abstracting away the database. KISS.
I would say that MVC makes more sense to me, since it feels better, but the only practical difference is that your login.php would contain both the model (data structure definitions) and the controller (code for page actions). You could add one file to the module, e.g. class.login.php and use __autoload() for that, which would essentially implement an MVC structure.
I have refactored a big PHP project to make it more MVC compliant.
I found especially usefull to create a DAO layer to centralize all database accesses. I created a daoFactory function, which creates the DAO and injects the database handle into it (also the logger, I used log4php, got injected).
For the DAO, i used a lot the functionalities of the database (mysql), like stored procedure and triggers. I completly agree with Doug T. about avoid over-abstraction, especially for database access : if you use the DB properly (prepared statements, etc.) you don't need any ORM and your code will be much faster. But of course you need to learn mysql (or postgress) and you become dependant on it (especially if you use a lot of stored procedure, like I tend to do).
I am currently refactoring a step further, using the Slim php framework and moving toward a restfull api : in this case there is no view anymore because everything is outputted as json. But I still use smarty because its caching works well and I know it.
Writing a framework could be a rewarding experience. The important thing to consider is that you do not write a framework for its own sake. The reason one writes a framework is to make development easy.
Since it is a personal framework you should think in terms of how it could help you develop with less hassle.
I do not think a template system is a good idea. Think of it - what is the major benefit of using a template system? The answer is that it helps teams with different skill sets jointly develop an application. In other words, some members of the team can work on the user interface and they do not need to be PHP coders. Now, a personal framework will most likely be used by a single person and the benefit of template system becomes irrelevant.
All in all, you should look at your own coding habits and methods and discover tasks that take most of your time on a typical project. Then you should ask yourself how you can automate those tasks to require less time and effort. By implementing those automation mechanisms you will have to stick to some sort of conventions (similar to an API). The sum of the helper mechanisms and the conventions will be your personal framework.
Good luck.
MVC doesn't work
you don't want to be constrained in the structure of your "modules"; also, keep templates close to the code (the templates directory is a bad idea)
no
re 1.: see Allen Holub's Holub on Patterns. briefly: MVC basically requires you to give up object oriented principles.
Tell Don't Ask is a catchy name for a mental trick that helps you keep the data and code that acts on it together. Views cause the Model to degrade into a heap of getters and setters, with few if any meaningful operations defined on them. Code that naturally belongs in the Model is then in practice spread among Controllers and Views(!), producing the unhealthy Distant Action and tight coupling.
Model objects should display themselves, possibly using some form of Dependency Injection:
interface Display
{
function display($t, array $args);
}
class SomePartOfModel
...
{
function output(Display $d)
{
$d->display('specific.tpl', array(
'foo' => $this->whatever,
...
));
}
}
OTOH, in practice I find most web applications call for a different architectural pattern, where the Model is replaced with Services. An active database, normalized schema and application specific views go a long way: you keep the data and code that acts on it together, and the declarative nature makes it much shorter than what you could do in PHP.
Ok, so SQL is a terribly verbose language. What prevents you from generating it from some concise DSL? Mind you, I don't necessarily suggest using an ORM. In fact, quite the opposite. Without Model, there's little use for an ORM anyway. You might want to use something to build queries, though those should be very simple, perhaps to the point of obviating such a tool...
First, keep the interface your database exposes to the application as comfortable for the application as possible. For example, hide complex queries behind views. Expose update-specific interfaces where required.
Most web applications are not only the owners of their respective underlying databases, they're their only consumers. Despite this fact, most web applications access their data through awkward interfaces: either a normalized schema, bare-bones, or a denormalized schema that turned out to make one operation easier at the price of severe discomfort elsewhere (various csv-style columns etc). That's a bit sad, and needlessly so.
re 2.: it's certainly good to have a unified structure. what you don't want to do is to lock yourself into a situation where a module cannot use more than one file.
templates should be kept close to code that uses them for the same reason that code that works together should be kept together. templates are a form of code, the V in MVC. you'll want fine-grained templates to allow (re)use. there's no reason the presentation layer shouldn't be as DRY as other parts of code.
I'm trying to design a solid server side architecture and came up with this :
http://www.monsterup.com/image.php?url=upload/1235488072.jpg
The client side only talks to a single server file called process.php, where user rights are checked; and where the action is being dispatched. The business classes then handle the business logic and perform data validation. They all have contain a DataAccessObject class that performs the db operations.
Could you point the different weaknesses such an architecture may have? As far as security, flexibility, extensiveness, ...?
Your architecture isn't perfect. It never will be perfect. Ever. Being perfect is impossible. This is the nature of application development, programming, and the world in general. A requirement will come in to add a feature, or change your business logic and you'll return to this architecture and say "What in the world was I thinking this is terrible." (Hopefully... otherwise you probably haven't been learning anything new!)
Take an inventory of your goals, should it be:
this architecture perfect
or instead:
this architecture functions where I need it to and allows me to get stuff done
One way that you could improve this is to add a view layer, using a template engine such as Smarty, or even roll-your-own. The action classes would prepare the data, assign it to the template, then display the template itself.
That would help you to separate your business logic from your HTML, making it easier to maintain.
This is a common way to design an application.
Another thing you could do is have another class handle the action delegation. It really depends on the complexity of your application, though.
The book PHP Objects, Patterns and Practice can give you a real leg-up on application architecture.
I see a couple of things.
First, I agree with others that you should add a view layer of some kind, though I am not sure about Smarty (I use it frequently and I am really having doubts these days, but I digress). The point is you need to separate your HTML somewhere in a template so it's easy to change. That point does not waver if you use a lot of AJAX. AJAX still requires you (usually) to put divs around the page, etc. So your layout should be separated from processing code.
The second thing I would throw out there is the complexity of your data model matters. If this is a straightforward CRUD application over an existing, or fairly flat, db model, you are probably fine with these db access classes. But, the minute your model gets to be more complex, with hierarchies or polymorphic in any way, this will break down. You'll need a more robust ORM of some kind.
Your "controller/dispatcher" methodology seems sound. The switch statements avoids the need for any kind of URL -> code mappings, which are a pain to manage and require caching to scale.
That's my $0.02
From a security perspective your class and action are coming in from your post variables and this can be dangerous because you should never trust anything coming from the user. Assumingly your class/action will look something like this:
class1
{
action1.1
action1.2
...
action1.N
}
class2
{
action2.1
action2.2
...
action2.N
}
As an attacker my first place to look would be getting into a state where an action doesn't match to it's appropriate class. I would try to submit class1 with action2.1 instead of action1.1.
With that said, my assumption is that you've already got some form of validation and so this wouldn't happen. Which leads me to my original post: If your architecture works for you, then it works for you. Take a look at the things which you're asking about: security, flexibility, extensibility and evaluate them yourself. Find your own flaws. If you don't know how to evaluate for security/flexibility/other read up on the subject, practice it and apply it.
You'll become a better developer by making mistakes and then learning from them (except missile guidance software, you only get one try there.)
Since others have suggested various changes like adding a view layer, etc. let me concentrate on the various criteria for a good architecture:
Extensibility: Usually, the more abstract and loosely coupled the architecture is, the more extensible it is. This is exactly why others have recommended you use a view layer which would abstract out the presentation layer templates for each class:action pair into its own file.
Maintainability: This goes hand-in-hand with extensibility. Generally, the more extensible the architecture is, the more maintainable it is (take that with a grain of salt because it is not always the case). Consider adding a model layer below your model logic layer. This would help you swap out your data access logic from the model business logic.
Security: The downside to the architecture you have posed is that you really need to invest in security testing. Since all your redirecting/routing code is in process.php, that file has a lot of responsibility and any changes to it may result in a potential security loophole. This isn't necessarily wrong, you just need to be aware of the risks.
Scalability: Your architecture is balanced and seems very scalable. Since you have it broken down by class:actions, you can add caching at any layer to improve performance. Adding an addition data access model layer will also help you cache at the layer closest to the database.
Finally, experiment with each architecture and don't be afraid to make mistakes. It already seems like you have a good understanding of MVC. The only way to get better at architecting is to implement and test it in the 'real world'.