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?
+15
A:
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).
Justin Niessner
2010-05-19 19:17:42
And I would add 'easier to maintain'. If they're not easier to maintain in the long run, you're doing something wrong.
Dan Esparza
2010-05-19 19:20:31
Ditto. Loose coupling, tight cohesion is always the way to go. One of the few good bits of info I took away from my SE class.
typoknig
2010-05-19 19:20:42
+1
A:
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.
duffymo
2010-05-19 19:18:35
+3
A:
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.
driis
2010-05-19 19:20:42
+1
A:
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.
dbyrne
2010-05-19 19:22:25
+1
A:
It will give you scalability. For example if you have service layer behind you can separate it in several servers. Also you will have less dependencies and modifications will be easier. Also code support will be easier.
Here you can see interesting small article : SOA - Loosely Coupled...What?
Shortly it says :
Loosely coupled systems provide many advantages including support for late or dynamically binding to other components while running, and can mediate the difference in the component's structure, security model, protocols, and semantics, thus abstracting volatility...
Incognito
2010-05-19 19:24:01
But what if I do not need to change components at runtime? I can't get your point about the scalability.
Rookian
2010-05-19 19:34:14
For example if you use SOA approach you can separate your services to work on different servers. Even if you don't need to change components at runtime you will have advantages from loosely coupled architecture. For example you are using MS SQL server as a DB and you are using ADO.NET as a data provider to interact with it. And once you will need to migrate to Oracle even to any other kind of data storage (even it could be xml files...) you will need to update all the modules dealing with it. But if you will have service layer for that you will need to modify only service layer.
Incognito
2010-05-19 19:43:55
So generally you can have as a rule - Change whatever you want, but not the contract.
Incognito
2010-05-19 19:44:40
+1
A:
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
Nicholas Murray
2010-05-19 19:38:47
A:
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.
Matt Sherman
2010-05-20 01:05:28