我有一个项目，我最近开始认真地工作，但与 friend 进行了一些设计讨论，我认为他提出了一些有趣的观点。
该项目被设计为具有高度可扩展性，并且易于完全独立地维护业务对象。易于扩展性迫使一些设计决策阻碍了项目的初始效率。
基本设计如下。
有一个用 ASP.NET MVC 编写的“核心”，它管理所有交互 JSON API 和 HTML web。但是，它不会创建或管理“业务对象”，如帖子、贡献者等。这些都是在它们自己单独的 WCF Web 服务中处理的。
核心的想法是非常简单地利用使用管理对象的单独控件从 Web 服务检索业务数据/对象。这反过来意味着核心可以是多线程的，并且可以同时调用页面上的控件。
每个网络服务将管理相关的业务对象及其在数据库中的数据。任何特定于业务的处理也将在这里进行，例如将表中的数据映射到有用的数据结构以供控件使用。整个对象将传递给核心，核心应该只在每个事务中检索或设置一次业务对象。如果将来需要多重影响操作，那么我将需要提供该功能。
Web 服务还可以执行自己的独立缓存，并且根据请求和他们自己对特定区域(例如用户)的了解，可以返回新创建的对象或预先创建的对象。
与 friend 交谈后，我有以下问题。
我知道 WCF 不如 DLL 调用或类似的东西快。但是如果整个系统都基于它们，会有多少开销？
创建线程的开销可能很大。这样做会比一个接一个调用所有控件的成本更高吗？
您是否可以在该设计中看到任何其他固有的陷阱？
最佳答案
除您的网站外，您是否还有其他网络服务客户？如果是这样，那么我认为 Web 服务并不是真正需要的。服务接口(interface)是合理的，但这并不意味着它必须是 Web 服务。使用 Web 服务，您将招致额外的序列化开销和更多的数据网络传输。您可能会为您的服务获得一些自动缓存功能，但听起来您无论如何都打算自己实现它。很难量化开销的数量，因为我们不知道您的对象有多复杂，也不知道您打算传输多少数据，但我敢打赌这并非微不足道。
如果是我，我会简化设计:采用单线程，使用嵌入式服务接口(interface)。然后，如果性能是一个问题，我会看看我可以通过缓存、多处理等解决现有的性能问题。这让实际的应用程序驱动设计，尽管在性能时你仍然会应用良好的模式和实践问题出现了。如果性能没有成为问题，那么您还没有构建很多复杂的基础设施——YAGNI!你不会需要它的!
关于c# - 网络应用设计，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/1940125/