[lmm]

The controller is always the ugly part, because it's the piece that's responsible for interfacing between transaction-specific logic and your general backend interface. The article is right that it's easy to put too much business logic in the controller, but fails to recognize that "MVC" isn't supposed to be your whole application - just the UI side. The functionality of this BorrowABook class doesn't belong in the UI layer at all.

[bshacklett]

MVC is something I've never really been able to wrap my head around. I wonder if this is why... All of the guides/articles that I've read on the subject have acted as if MVC was how the entire application was handled.

Could you recommend any references for back-end patterns?

[icebraining]

I like Patterns of Enterprise Application Architecture, which includes some domain logic patterns. A common one is SOA, by dividing the backend into services that your UI consumes.

[nbevans]

Controller is an adapter or anti-corruption layer designed to couple together two separate bounded contexts. It's feasible and likely there would be two variants of BorrowABook, one in the UI model and one in the service/domain model. They may be subtly different in what fields they hold.