当我看看ASP.NET MVC项目我每次看到松耦合架构。
在Web架构中我需要什么松耦合(如果我不进行单元测试)？
这有什么优点和缺点？
解耦层/类的主要原因是什么？
如果我不想更改我的DAL如果怎么办？我的意思是什么时候我改变我的整个DAL？所以我可以把我的DAL到UI。这是什么坏？
解决方法
它将为任何不太小的项目节省大量时间，其中我定义小到小于几千行代码(取决于语言)。
原因是，一旦你超越了超级小项目，每个变化或更新变得越来越紧密耦合。松散耦合使您能够继续前进，添加功能，修复错误等。
在某一点我认为任何程序成为一个噩梦来维护，更新和添加。设计越松散耦合，该点被延迟的越远。如果它紧密耦合，也许在大约10,000行代码之后，它变得不可维护，添加一些功能变得不可能，没有从头开始重写。
松耦合允许它增长到1,000,000-10,000行代码，同时仍然能够在合理的时间内进行更改和添加新功能。
这些数字并不意味着从字面上来看，因为它们只是组成，但要给出一个感觉，它变得有帮助。
如果你永远不需要更新程序，它是相当简单，然后肯定，很好紧密耦合。甚至可以开始这种方式，但知道什么时候分开的东西，但你仍然需要经验编写松散耦合的代码，知道在什么时候它变得有益。
Enterprise Fizzbuzz是一个故意幽默的例子，说明如何利用overengineering进行舷外，而不是每个项目都需要相同级别的去耦。
MVC通常被认为是一个很好的起点，因为大多数项目将变得足够大以使其有所帮助。当项目变大时，该去耦的水平是不够的，并且M部分需要被本身分割成若干层，等等。没有一个大小适合所有，但MVC是大多数项目的脱钩。
