MVC is dead, it's time to MOVE on

The problem with MVC is that it makes people think that there are only supposed to be three things, and if something they require doesn't fit into thing 1, and doesn't fit into thing 2, then it must go into thing 3, instead of inventing a new thing 4 for it. Most real-world software is complicated enough that it requires more than three pigeon holes. Cargo-cult MVC programmers who can't think outside of three boxes are why the Controller usually gets gang[4]-banged into a kitchen sink of everything that didn't fit into the model or the view, because the words "Model" and "View" have easily understood meanings, but "Controller" could mean anything, so it gets some of everything.

(In my experience most Wikipedia edits are gratefully received, assuming you provide references for your claims. Kind of like HN, really)

I want an email to be sent to me when the quantity on hand of a part gets below the re-order point.

So now, I build a program that listens for notifications, and when it gets one, loads the data, erases the queue, and sends me an email.

I build this so the app itself doesn't know this is required or is going on. Database triggers, queue tables listening scripts, and templates all are triggered when the db write takes place.

Now, what we have here are arguably two MVC environments where the model behavior of one triggers a model change in another, which triggers a controller to run, calls some other model stuff, creates an email (via a view) and sends it.

But this is the sort of action you are talking about, right? You think this violates separation of concerns?

Unfortunately, the wrong choice comprises nearly half of comments made. You were obviously right the first time - let it lie :)

My point though is in essentially shimming functionality. In my example, for example, here is how it would work.

1) User requests "save this invoice", which activates a controller script which automates the model elements for "invoice" instantiates an invoice (since this is a stateless web app) and saves it.

2) The model saves the invoice by writing it to the db.

3) Saving to the db fires a trigger which checks ROP vs on-hand and where ROP is greater saves a record in a queue table and issues an asynchronous notification, which doesn't have any immediate effect.

4) Controller commits the db transaction. The DB sends out the notification and makes the rows in the queue table visible.

5) Controller for application b wakes up (let's say every 15 min) and polls for notifications. Ok, we got one. Look up the queue table, prepare the email (model stuff) runt he template (view stuff) and sent it out (model stuff again).

So what I am getting at here is a way to have model events have side effects which are outside the scope of Application A, but are at least triggered by model operations. This is not an anti-pattern really because application A is not relying on those side-effects for operation. However if you look at application A as the primary one and application B as contained within it, then application B can only be described as contained within the model of application A, from application A's perspective, because all of its functionality is abstracted behind the model. From application B's perspective, there is a model, a view, and a controller, and it doesn't care as to where notifications and queue table data is coming from. From it's perspective it is a loosely coupled app in its own right.

But as always what I am suggesting is that common sense usually determines the best place for a given piece of logic. LedgerSMB is very model-centric but there are cases where we have a fair bit of logic in the controller.* I think that anything which is inherent in the model belongs in the model. So back to the vehicle analogy, a bike object should support a $bike->turn('l') and a $bike->turn('r'). However telling the bike when to turn left is the controller's job.

* for example in contact and employee management, the controller has to coordinate a lot of different model operations, leading to unusually long/complex model code in the system.