Why should a web architecture be loosely coupled?

Question

When I look at ASP.NET MVC projects I everytime see loose coupled architecture.

For what do I need a loose coupling in a web architecture (if I do not make unit test

Answer 1

Responding with an angle noone else discussed; temporal decoupling. It can be done in a few ways:

• Queue-based architectures where the web places messages in a queue and listens for results
• Avoiding blocking operations, primarily by using the async pattern or an async monad that binds continuations to callbacks of operations, letting the threads do work while waiting for IO. Example: http://blogs.msdn.com/b/dsyme/archive/2007/10/11/introducing-f-asynchronous-workflows.aspx or http://en.wikibooks.org/wiki/Haskell/Continuation_passing_style
• Push-based architectures (AMQP basic_consume e.g.)
• Fork-join patterns
• ...

When using the above (except the async monad), you often deal with messages explicitly rather than method invocations. This leads to thinking correlating with how message passing works (idempotence of handling them, queues for storing them in transit, security data attached to their envelopes, retry logic in handlers rather than requestors, ...).

By moving towards message-oriented architectures that are temporally decoupled you can make it easier to extend the application - especially if you have mostly doing publish-subscribe (see also, event driven architecture) - anything may listen to events and react on them and you don't bind the implementations of integrators to the initial call sites.

Web sites that push work onto queues are more responsive in general, because they don't let worker threads hang around waiting for IO to happen. They are also often cheaper to maintain in the long run.

For different types of compile-type coupling (and other metrics), browse http://www.ndepend.com/Metrics.aspx and read some about it yourself.