Web应用程序设计

Question

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

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

基本设计如下。

在ASP.NET MVC中有一个“核心”，它管理着所有的交互JSON API和HTML网页。然而，它不创建或管理像发布，贡献者等“业务对象”。这些都是在他们自己单独的WCF Web服务中处理的。

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

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

此外，Web服务可以执行自己的独立缓存，并根据请求以及他们自己对其特定区域的知识（例如用户）可以返回新创建的对象或预先创建的对象。

与朋友谈话后，我有以下问题。

1. 我明白，WCF不如DLL调用或类似的东西快。但是，整个系统是以多少开销为基础的？

2. 创建线程可能很昂贵。比起只是一个接一个地调用所有的控件，花费更多吗？

3. 在这个设计中你可以看到有其他的内在坑吗？

Answer 1

您是否有其他客户用于网站之外的网络服务？如果是这样，那么我认为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调用。这是很大的开销。