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

It all depends on the intent of making the Application along with the business interest. If business is keen to scale it and enough fuel (read corpus) is involved which gives enough thought to the architect to make the application reap long term benefits.

So the advantages are :-

1) If you are using a third party control/code : Always write a "wrapper/adapter layer" so that for any reason if that is not usable you can get something else and change the adapter layer without disturbing your application repository code.

2) Encapsulating specific complex functionalities in a "Service Layer" which may or may not require database requests : Its beneficial because as the request and response remains the same (it can surely change with time as well), you can always work on the performance of that specific code without changing the output. With unit cases in place we can also measure the performance of the code.

3) Making specific roles write specific code : If we create a lot of roles, it comes easier for people in the team to focus in their specific repository instead of getting lost in the pile of not related code.

4) Focussed QA : If we have layered architecture, it always helps to better the QA as its focussed.

5) Finding/Solving Bugs : Using layered architecture and assuming you have good logging in place, it always saves time to find the bugs and resolve it.

Disadvantages are :-

1) Setting up an application with this kind of framework will take extra time. So "go to market" will be delayed.

2) If you get too technology enthusiast it might end up in over kill.

3) Extra transaction latency: As the data travels through various layers there is extra latency which gets added in each transaction.

About changing the DAL :-

Of course there will be a time, when performance will take priority over features at that time you will have to start considering your data providers leading to the change in DAL.

If you couple your DAL to your UI, everytime you change your DAL (if at all, when at all) you always would require to re-release the entire binaries in production. Which has its own set of issues (am shying away to explain it here, if you require I can always include that)

That's the reason, initially its always better to spend time and conclude when will the "self destruct" happen for the application. I meant what's the life of the Application, if this is answered well, rest everything will fall in place.