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

A loosely coupled architecture will help you when your application needs to change or grow. And any non-trivial application will eventually need to change or grow.

If you design with a loosely coupled architecture, only a few parts of the application should be affected when requirements change. With a too tight coupled architecture, many parts will need to change, and it will be difficult to identify exactly which parts will be affected.

One of the main benefits of TDD, in my opinion, is that at helps promote a loosely coupled architecture.

Answer 2

First off, you should be writing unit tests ;)

Say you end up needing to change the underlying database. If your data access code is tightly coupled to your business logic, this could prove to be a huge effort. With loosely coupled code, your business logic will remain unaffected.

What if you decide you want to write some command line utilities that leverage your backend components? Providing multiple entry points to your system is much more easily accomplished with loosely coupled code.

Answer 3

It will save you a lot of time for any project that isn't trivially small, where I define trivially small as less than a couple thousand lines of code (depending on the language).

The reason is that once you get past super small projects, each change or update gets harder the more tightly coupled it is. Being loosely coupled enables you to keep moving forward, adding features, fixing bugs, etc.

At a certain point I think any program becomes a nightmare to maintain, update and add on to. The more loosely coupled the design is, the further that point is delayed. If it's tightly coupled, maybe after about 10,000 lines of code it becomes unmaintainable, adding some features become impossible without essentially rewriting from scratch.

Being loosely coupled allows it to grow to 1,000,000 - 10,000,000 lines of code while still being able to make changes and add new features within a reasonable amount of time.

These numbers aren't meant to be taken literally as they're just made up, but to give a sense of where it becomes helpful.

If you never need to update the program and it's fairly simple then sure, it's fine to be tightly coupled. It's even okay to start that way but know when it's time to separate stuff out, but you still need experience writing loosely coupled code to know at what point it becomes beneficial.

Enterprise Fizzbuzz is a intentionally humorous example of how it's possible to go overboard with overengineering, and not every project is going to need to same level of decoupling.

MVC is generally considered a good starting point because most projects will become big enough for it to be helpful. When the project gets bigger, that level of decoupling isn't enough and the M part needs to be split into several layers itself, and so forth. There isn't a one-size fit all, but MVC is a good amount of decoupling for most projects.

Answer 4

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.

Answer 5

Loose Coupling allows you to make changes in one area of the application without affecting the others. Theoretically it allows you to do things like change your Data Access Layer without rebuilding your Business or UI Layers.

It definitely makes your applications more flexible, more adept at change, and easier to maintain (since you don't have to worry about a change in one area of the application breaking another).

Answer 6

Because the stuff in the back might be useful even if it's not communicating with a browser-based, HTTP web UI. So you want to be able to disconnect it from that particular UI.