3 ms·

This is very unclear - the database is not the model in the app, it's the storage for the model. (In its own application though, it may be a model...) You've a

by drone 14y ago

This is very unclear - the database is not the model in the app, it's the storage for the model. (In its own application though, it may be a model...) You've abstracted some application functionality into the data storage, ok. I'm speaking to the point that if you are separating Model, View, and Controller, and you have complex objects in your model that can do many things, it would not make sense to put all of the logic about what those things can do, how to do them, and when to do them in the model. Otherwise, you're simply blending the model and the controller (which may not be a wrong thing to do) - so you just have MV. Let me give a more concrete example: I have a model which represents a network of connected complex "devices," there are five types of devices, each that can do 50 distinct things. The model can add a new device, delete a device, or retrieve an existing device. It can also ask the devices what their names, and addresses are, and what features they support, on behalf of any view which needs that information. It cannot, however, tell device 1, which is of type X to take action "foo". That, instead, is implemented by a controller attached to a view that shows a big button that says "Do Foo", and a drop-down with the list of available devices that can do Foo. The view passes the press of the button onto the controller, which asks the model for the selected device, and then executes a "do Foo" command on it, and then, perhaps, contacts the device again to check that "Foo" was completed. If all such logic were built into the model, I'd have several hundred methods in it, and I'd be very quickly looking for somewhere to move all of this logic, like, you know, controllers.

einhverfr 14y ago
The database is not the model but the db operations are usually in the model, right? 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.

by drone 14y ago

einhverfr 14y ago

The database is not the model but the db operations are usually in the model, right? 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.