Download to read offline
Uploaded byDr. Syed Hassan Amin
Thin Controllers Fat Models - How to Write Better Code
This document discusses the proper implementation of the MVC design pattern compared to common anti-patterns. It emphasizes that the model should contain all business logic, while the controller acts as a thin translator between the user, model and view. The view simply displays data from the model. When implemented correctly with thin controllers and fat models, MVC promotes separation of concerns, reusability, and testability. Common mistakes include putting too much logic in controllers or allowing direct access between views and models. The document provides examples of proper and improper implementations of each MVC component in various languages and frameworks.
More Related Content
Similar to Thin Controllers Fat Models - How to Write Better Code
Thin Controllers Fat Models - How to Write Better Code
- 1. Thin Controllers - Fatmodels How to write better code - MVC - Adapted by Dr. Syed Hassan Amin
- 2. Introduction • MVC isone of the most common design patterns • It is used in Android, iOS and web applications. • Most developers are confident about having good, practical knowledge of this pattern. • MVC pattern is perhaps the most abused design pattern.
- 3. Points to Ponder •What is anti-pattern ? • What is dumb data holder ?
- 4. Fat Controller AntiPattern • The anti pattern that identifies misuse of MVC pattern is Fat controller. • Fat controller has overly complex logic and domain concepts. • Domain logic should be completely separate from controllers so that it can be easily extended, and reused. • Putting domain concepts in controller stinks, and results in strong coupling between domain logic, controllers and view.
- 5. WARNING: Do nottry it at home/work! The WRONG way - "mvC"
- 6. mvC - Controller ●Whole business logic in a Controller. Controller: I'll do everything for you. You can keep everything in one place. That's so simple!
- 7. mvC - Model •Models used basically just to store data in database. • Model – I'm just a data so why should I do anything more than just exist?
- 8. mvC - View •View uses the database directly • Just give me database connection and I'll do everything! • View – Give me more power and you won't need controllers and models at all!
- 9. mvC - problems? ●Copy/Paste to "reuse" the code. ● Long and complex methods (actions) that need to be copied in order to use polymorphism. ● Very difficult to test.
- 10. You will payfor mvC
- 11. Makes your lifeeasier The RIGHT way - MVC
- 12. MVC - Controller ●Just a translator for a user wishes (request) so model and view can understand and respond in proper way (response). Controller: I should be so thin you should barely notice me. I'll just tell model what user did and the view to show what he wants - facade for business logic.
- 13. MVC - Model ●This is where whole "magic" should happen. ● Model should store and manipulate data. ● It should be used intensively by controllers to do what user requested and by views to show data user wants to see. ● Business logic should be in models, eg. "$ageLimit > 20". Model: I'm the proper guy for doing the hard work. I know how your app should work and why.
- 14. MVC - View ●Gets a model or a collection of models selected by controller (according to user request) and shows it. ● It tells the controller what user has done and what does he expect to happen. View: I'll show you what you want and let you do cool things with models.
- 15. MVC - Actionhelper ● Easy and good way to reuse code between controllers. ● Thanks to models it's using it keeps things DRY. ● Prefer action helper over methods put in controllers extended by other controllers. Action helper: I can do common things with the models according to the request. I'm the controllers ... helper.
- 16. MVC - Viewhelper ● Helps you render HTML template that you use on many views. View helper: I can help you make things (php, js and html code) look nice.
- 17. OOP - Model ●If you think you're using OOP because you have classes - you are wrong! ● "Happy" object should have just one responsibility. "Fat model" does not mean it has to have hundred lines of code. ● Object should be easy to test. You should be able to "mock" things it's using. ● Let object be dependent - inject into it the things it needs.
- 18. MVC- Web Applications •When developing web applications, there are many traps regarding use of controllers : – Controller per Page : In this case you will end up creating too many controllers. However, controllers can handle more than one page. – Controller per Entity : This approach is too granular and may become even more challenging when we have more than one entity per view. Rails and Code Ignitor have this sort of controller per model approach. • It is advisable to write single test class per controller and prefer using MVC pattern. PHP OOP provides great functionality to avoid tight coupling.
- 19. MVC - JavaScript ●All those rules applies to JavaScript and other languages. ● JavaScript code is also great when you use MVC! So you should/could have: MV(JS: MVC)C
- 20. Zend Framework usesMVC - really? ● It's not a "true" MVC. ● MVC was designed for desktop apps. ● It has many "branches". @see MVP @see Model2 ("MVC for web apps")
- 21.