当我查看ASP.NETMVC项目时，我每次都看到松散耦合的体系 struct .
在web架构中，我需要松耦合做什么(如果我不进行单元测试)？
advantages和disadvantages是什么？
解耦层/类的main reason个选项是什么？
例如，如果我不想更改DAL，该怎么办？我是说我什么时候才能换掉我的整个DAL？！这样我就可以把我的DAL和UI结合起来.这有什么不好？
当我查看ASP.NETMVC项目时，我每次都看到松散耦合的体系 struct .
在web架构中，我需要松耦合做什么(如果我不进行单元测试)？
advantages和disadvantages是什么？
解耦层/类的main reason个选项是什么？
例如，如果我不想更改DAL，该怎么办？我是说我什么时候才能换掉我的整个DAL？！这样我就可以把我的DAL和UI结合起来.这有什么不好？
它将为任何不是非常小的项目节省大量时间，我将非常小的项目定义为少于几千行代码(取决于语言).
原因是，一旦你通过了超小型项目，每一个变更或更新都会变得越困难，因为它们之间的耦合越紧密.松散耦合使您能够继续前进，添加功能，修复bug等.
在某种程度上，我认为任何程序都会变成一场噩梦，需要维护、更新和添加.设计的耦合越松散，该点的延迟就越大.如果它是紧密耦合的，可能在大约10000行代码之后，它就变得不可维护了，如果不从头开始重写，添加一些特性就不可能了.
松散耦合允许它增长到1000000-10000000行代码，同时仍然能够在合理的时间内进行更改和添加新功能.
这些数字并不是字面意义上的，因为它们只是虚构的，而是为了让人感觉到它在哪里有用.
如果您永远不需要更新程序，并且它相当简单，那么可以肯定的是，紧密耦合是很好的.这样开始甚至是可以的，但是知道什么时候可以把东西分离出来，但是您仍然需要有编写松耦合代码的经验，才能知道在什么情况下它会变得有用.
Enterprise Fizzbuzz是一个故意幽默的例子，它说明了过度工程是如何可能走得太远的，而且并不是每个项目都需要相同级别的解耦.
MVC通常被认为是一个很好的起点，因为大多数项目都会变得足够大，从而对它有所帮助.当项目变得更大时，这种级别的解耦是不够的，需要将M部分本身拆分成几个层，依此类推.没有一刀切的解决方案，但是MVC对于大多数项目来说是一种很好的解耦方式.