用传统的思维方式（记住DNA？）我们应该通过将层分成服务来构建我们的应用程序。在实现ASP.NET MVC应用程序时，为什么要真正实现额外的服务并将WCF引用包装到单独的dll中，而不是让Web应用程序直接引用WCF？
我可以想到两个论点，以及对这些论点的一些想法：
另一方面，人们可能会过度体系结构，因为实施很多层只会给解决方案带来更多的复杂性，并且不会带来预期的好处。
答案 0 :(得分：1)
我实际上不是仅仅因为“因为”而引入额外dll的粉丝。到过那里; T恤上有依赖图。如果您无法在环境/上下文中明确定义的好处，那么就做最简单的事情 - 这可能是Web应用程序的引用。
我听说过允许重复使用的论点，但反驳：soap / mex已经非常明确地定义了这一点。另一个论点是可测性，隔离，分离等;这一切都取决于这些你（或者更确切地说：你的团队）在你的用途中给予多少好处。
对于单独的dll，一个非常有效的情况是，当您（主要是内部应用程序）在WCF服务器和客户端之间共享DTO库时，这两者都有丰富的对象而不是简单的阴影。在这种情况下，我不会（从语调中）收集这一点。