Notes regarding http://t.co/HRNF1yytli

gistfile1.md

Few notes on the subject

• the three sets of structures from model layer, that you mention, are not the only ones. Only the most common. In larger application you may find, that you also need repositories and units of work. Also I am not entirely sure whether "collection of domain objects" should be mentioned separately or not.

• there is very little if at all written about ui layer in proper literature. I have found only few snippets from Fowler and that's about it. And most of the content is aimed towards desktop software.

• controllers do not really do "perform authentication, dispatch requests, render output". Those could be called: external concerns. Your framework/infrastructure supplies the controller with per-processed user input (as arguments or Request class instance) and then controller decides on how to use this input to alter the model layer's state. That's it. The parts that you mentioned before are stuff done in front controller (which is a different from mvc's controller and another case of shitty naming) or the bootstrap-phase websites .. and this bit can and should be handled by the framework/infrastructure.

• the MVC pattern was never intended for web and in my experience it translates very poorly. You should care less about whether "is it the real MVC" and more about "is this a good architecture". If you need to sell it to someone, who has been drip-fed the framework hype, you can simply say: it has been inspired by MVC.