Can someone please explain this chapter for a retard? It

>>373676
Okay, so the Model is supposed to sit between the underlying storage and the Controllers and Views, representing the data, and providing *semantic* operations to modify it.

Say you have a site that sells stuff. Your Model might have methods to sell a product, and to check in more products from the wholesaler. These are semantic operations: they're real things that are being done to real things. What your Controller is supposed to be doing is saying to the Model "hey, this guy just bought a skateboard", and the Model is supposed to be sorting things out. It's supposed to be abstracting the actual details of the operation from the controller, so that the actual details are contained in one Model, not a bunch of Views and Controllers.

The antipattern in that chapter is when actual implementation details start oozing out past the controller into the Views and Controllers. The Model isn't serving as a barrier to keep the implementation details out of them, and now not only are they in the Controller where they don't belong, they're duplicated across all the Controllers, and not necessarily the same way each time.

Now your example Controller, instead of saying "Model, this guy bought a skateboard, sort it", is now saying "Model, decrease the number of skateboards in the stock table by one, and create a new order for this guy, and add a skateboard to it, and add a skateboard to the next order from the wholesaler, and email Jeff". This causes several problems:

- Model code in the Controllers means the skateboard can now get sold differently depending on which Controller sold it
- code to turn data into semantic things is duplicated across all Views and Controllers, which means more coding and more testing
- the controller now depends on internal details of the storage layer beyond the Model, so it can't be tested without the actual Model and storage layer being there
- you can't unit-test the controllers; every test tests the whole stack

File: model doing its job.png (71KB, 508x675px) Image search: [Google]

71KB, 508x675px

>>373676
If you take nothing else away from this chapter, it should be these two figures.

In the top one, there are several "Models", but they're not real models, they're just DAOs, and the Model work is being done in the Controllers. Everything is a mess.

In the bottom one, the Model is doing its job. It's providing an interface full of semantic operations for the Controllers to call, and it's hiding the details of the database tables from them. The Controllers don't need to duplicate code, and they're not coupled to a load of stuff that isn't their job. Now if you want to test the Controllers, you can unit test against a stub Model, and if you want to test the Model you can unit test most of it against a stub database.

>>373681
>>373691
Yo, thanks a bunch anons.

>>373691
Also, one more question. Are the active records on the bottom panel the stub models?

>>373697
They're either real Database Access Objects or stub DAOs; the whole point of stubs is that (for the purpose of unit testing) they're indistinguishable from the real thing.

>>373702
Ahhh, so there is a singular model for "Bugs" while there are individual DAOs for the model to access?

>>373703
You got it. The Bugs model receives queries about bugs ("find this bug", "delete this bug", etc.) and generates the DAO quieries needed to satisfy them.

It doesn't let the controllers talk to the DAOs or the DAOs talk to the controllers, because its job is to be a go-between.

>>373719
Oh, that makes sense. Thank you so much anon!