Fat models are slightly better than having that crud in your views, but they're still an antipattern. Models should describe the relationships between entities in your business, not be the junk drawer for stuff that doesn't go anywhere else.<p>Fat models are already a code smell, but passing the request object to your model should really set off alarm bells. You've now made it extremely messy to use your models outside of a web context, making it impossible to unit test them, and pretty much wiped out the purpose of the controller as an encapsulation layer.<p>Domain-driven design (DDD) provides a lot of patterns that help to keep from either having model code in your views, or these types of junk drawer models.<p>Basically, DDD as it applies to MVC webapps is: If it's a complex query of some sort, create a query repository that returns model objects rather than a "fat" static method on the model itself. If it's a business transaction, create logic objects that encapsulate the biz logic, and service objects that applies the logic to the models. The controller serves as the broker between requests, services, and entities. You end up with much more testable and reusable code this way.