网页应用程序设计

Question

我最近开始认真开展一个项目，但与朋友进行了一些设计讨论，我认为他提出了一些有趣的观点。

该项目旨在具有高度可扩展性并且易于完全独立地维护业务对象。易于扩展性迫使一些阻碍项目初始效率的设计决策。

基本设计如下。

有一个用 ASP.NET MVC 编写的“核心”，它管理 JSON API 和 HTML web 的所有交互。但是，它不会创建或管理“业务对象”，如 Posts、Contributors 等。这些都在它们自己单独的 WCF Web 服务中处理。

核心的想法是非常简单地利用单个控件，这些控件使用管理对象从 Web 服务中检索业务数据/对象。这反过来意味着核心可以是多线程的，并且可以同时调用页面上的控件。

每个 Web 服务都将管理数据库中的相关业务对象及其数据。任何特定于业务的处理也将在此处进行，例如将表中的数据映射到用于控件的有用数据结构。整个对象将被传递给核心，并且核心应该只在每个事务中检索或设置一次业务对象。如果将来需要多重影响操作，那么我需要提供该功能。

Web 服务还可以执行自己的独立缓存，并且根据请求和他们自己对特定区域（例如用户）的了解，可以返回新创建的对象或预先创建的对象。

和朋友聊完之后，我有以下问题。

1. 我很欣赏 WCF 不如 DLL 调用或类似的东西快。但是如果整个系统都基于它们，会有多少开销呢？

2. 创建线程可能会很昂贵。这样做会比一个接一个地调用所有控件的成本更高吗？

3. 您是否可以通过这种设计看到任何其他固有的坑式瀑布？

Answer 1

除了您的网站之外，您还有其他 Web 服务客户端吗？如果是这样，那么我认为 Web 服务并不是真正需要的。服务接口是合理的，但这并不意味着它必须是 Web 服务。使用 Web 服务会产生额外的序列化开销和数据的网络传输。您可能会为您的服务获得一些自动缓存功能，但听起来您无论如何都打算自己实现它。很难量化开销的数量，因为我们不知道您的对象有多复杂，也不知道您打算传输多少数据，但我敢打赌，这并不是微不足道的。

如果是我，我会简化设计：采用单线程，使用嵌入式服务接口。然后，如果性能是一个问题，我会看看我可以通过缓存、多处理等解决现有的性能问题。这让实际的应用程序驱动设计，尽管你仍然会在性能时应用良好的模式和实践问题突然出现。如果性能没有成为问题，那么您还没有构建很多复杂的基础架构——YAGNI！你不需要它！

Answer 2

1. 这取决于您的服务调用的粒度。 SOA 中的一个原则是让您的界面不那么啰嗦，即让一个调用执行一大堆操作。如果你把你的服务接口设计成一个常规的业务对象，那么它很可能会太健谈。

2. 这取决于您的使用模式。同样关于线程，粒度也是一个关键因素。

3. 看起来很像您过度设计了系统。更改服务接口比更改简单的方法签名要麻烦得多。如果您的所有业务对象都公开为服务，那么您将面临调试噩梦。

Answer 3

1. 如果您有一个或多个非本地客户端（无法直接访问您的逻辑），则面向 Web 服务的设计是合理的。例如 AJAX、Flash、来自不同域的另一个 Web 应用程序等。但是当您可以直接调用您的逻辑时为您的应用程序使用 WCF 是非常糟糕的主意。

如果以后您需要 Web 服务，您可以使用 Service Layer 轻松包装您的域模型。

2. 必要时使用线程池来最小化线程创建调用。这个问题的答案取决于你需要实现什么，从你的解释中不清楚。

3. 主要的坑是你试图使用很多东西。过度设计可能是个好词。

Answer 4

如果您担心调用 WCF 服务的开销，那么您可以使用null transport。如果客户端和服务器位于不同的机器上，这可以避免所有必要的序列化和反序列化。

Answer 5

这听起来不像是具有高度可扩展性的东西；至少，每秒不会有很多用户。通过创建比您需要的多得多的线程，到处使用 WCF 会减慢速度。如果 WCF 调用没有做太多工作，那么线程开销会严重伤害您。尽管它将是多线程的，但对 ASPX 页面的多次调用已经是多线程的。当只有一个人在运行时，您可能会加快系统速度，但如果有很多用户在运行，则会严重影响性能。例如，如果一个用户请求该页面，那么十个单独的 WCF 调用可能会从多线程中获益。但是，如果您每秒有 100 个页面请求，那就是每秒 1000 个 WCF 调用。这是很多开销。