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 tests)?

What are advantages and disadvantages of this?

What is the main reason to decouple layers/classes?

What if I do not want to change my DAL for example? I mean when shall I change my whole DAL?! So I could couple my DAL to the UI. What is bad with this?

Answer 1

Advantages:

• Scalability - allow you to expand out a database access layer
• Swapability - eg email provider code
• Maintainability - just change the code in one place
• Ease of setting up Unit Testing - you can Mock objects like your databse

Disavantages:

• Several extra lines of code perhaps
• Some extra interface classes

Answer 2

The main reason to couple and decouple the classes is for extendability. The Change in one should not affect other.

if you build an application that is currently using MYSql database to store the data. Now we have new requirement to store the Data in MSSQL as his backend system. What Solution are you left if you build the system more integrated with MYSQL Libraries. To Rewrite the Whole application for MSSQL. Now how about this We build a new DAL based on MSSQL and plug the Dal into the system without making any changes to the system (UI).

The Application is calling the routine based on interfaces and interfaces are free from implementation.

Try reading about Unity or MEF these topics will provide you good insight

Answer 3

Division of labor, which is the human equivalent of separation of concerns. Your HTML guru should be able to work independently of your SQL goddess.

A dramatic change to the front end should be able to proceed without tearing up the backend, and vice versa. In other words, you should only have to hire one person instead of two.

Answer 4

On the paper, there are many advantages of loose coupling, but in practise, it's hard to make it right IMHO. Here are some advantages:

• Systems can evolve independently in terms of lifecycle.

• Systems can be written in different languages, and ultimately run on different OSes.

• Systems can (and should) be built by different teams. You can outsource the development of systems. This is in fact almost the only way to scale a software development organization.

Here are some disadvantages though:

• It's more work at the beginning, and if you don't do it well, you may never see the benefits of it.

• Defining APIs/Contracts is quite difficult and requires very experienced developers. It's easy to do initially, but its hard on the long run.

• Generalization of loose coupling can in fact lead to loose typing everywhere. Instead of using clearly defined meaningful objects, you may observe an increase in the usage of 'object' parameters or return type, of generic types added to every class or interface. The bad effect of this is the average developer will probably add wild cast operations everywhere, assuming types on both sides of the so-called loosely coupled systems.

• Some loose coupling techniques are based on the generalization of interfaces definition, with an intent to avoid direct dependency. Remember an interface is supposed to be carved in stone once defined and published. Now, that's not really what I call loose coupling. A .NET class, leveraging the JIT and techniques such as method overload can be a better loose coupling instrument. So, the problem with these interfaces and factories everywhere is it will lead to a multiplication of types, assemblies, test cases, etc... and simply more work and complexity down the road. Instead of simplifying things, instead of building one system, you'll have to build many. "an N-tier system is N-times the work" :-)

• Loose coupling somehow bypasses one of the most powerful tool ever created: the compiler (C# or others). And that's the whole purpose of it actually, but it definitely has some drawbacks because all the ground work the compiler was doing (type checking, etc...) will need to be done elsewhere (tests), and that will have a cost.

• Many out-of-the-box tools will probably not work any more. You will not be able to use things such as Visual Studio "Go To Definition" or "Find All References".

Answer 5

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 6

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.