Menu
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?
303
Building and deploying applications using a service-oriented architecture provides an environment for loose coupling between components. The benefits of loose coupling include location transparency, protocol independence, and time independence.
Building and deploying applications using a loosely coupled architecture provides various advantages like scalability, resilience, maintainability, extensibility, location transparency, protocol independence, time independence, systems become more scalable and predictable.
Loosely coupled architectures can also allow for more independent scaling. For example, in a loosely coupled network, engineers could work on improving the capacity or performance of one node with less effect on the other nodes in the system.
Tight coupling means classes and objects are dependent on one another. In general, tight coupling is usually not good because it reduces the flexibility and re-usability of the code while Loose coupling means reducing the dependencies of a class that uses the different class directly.
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).
96
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.
20
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With
