ASP.NET Web 应用程序架构设计建议

Question

以前我的 ASP.NET Web 应用程序直接使用 ADO.NET 连接到数据库。现在我想把它改成3层，ASP.NET层，中间Web服务层和后端数据库层。我认为这样做的好处是我可以将数据源抽象到 ASP.NET 前端，松散耦合并减少潜在的安全风险，让外部暴露的 ASP.Net Web 应用程序能够直接访问数据库等。

与 2 层架构和 3 层架构相比，我遇到了 2 个主要问题。

1. 额外的中间 Web 服务层将产生更多流量，例如ASP.NET 不直接与数据库对话，而是与 Web 服务对话，而 Web 服务与数据库对话，会产生更多流量。会不会是瓶颈？如果这是一个瓶颈，有什么解决这个问题的一般建议吗？

2. 由于 ASP.NET 不能连接到数据库，而是连接到 Web 服务，因此无法轻松获取 DataSet/DataTable 对象。很难将表格数据呈现给数据绑定控件。有什么想法可以让 ASP.NET 中的表示层更容易编码？

问候，
乔治

Answer 1

如果你只是认为有好处，你就不应该这样做。您正在谈论以牺牲性能、代码简单性和架构简单性为代价增加大量复杂性和为自己工作，因为……什么？你得到了什么值得这些成本？

你：

• 有紧急的安全相关需求，需要断开 Web 前端与数据库服务器的连接（不，不是假设的“我打赌这会更安全”，而是可以证明的，具体的安全问题通过了解您授予的数据库权限来解决问题您的 ASP.NET 应用程序）

• 预计在未来某个时间点（可能会重复）完全交换您的数据层，因此需要将您的 Web 代码库与彻底的 DB 更改隔离？

在几乎所有情况下，这些问题的答案都是否定的。这样做只会给您自己和其他可能接触此应用的人增加痛苦。

Answer 2

关于您的问题 #2 - 您当然可以从 Web 服务返回一个 DataSet。 http://tinyurl.com/ah58xc

但是，也许更好的选择是简单地重构您的应用程序，而不是使其成为多层。例如，将“数据访问”分离到您从 ASP.NET 项目中引用的单独的类库项目中。这可以使事情更有条理，并可能完成您想要通过多层架构完成的一些事情。

顺便说一句，在您可能不一定需要多层时创建多层的最大危险是您最终会创建“代理”代码，因为没有更好的术语。也就是说，除了调用具有相同参数的“真实”后端方法之外没有其他用途的方法。一开始感觉更好，因为你有一个干净的层分离，但会导致维护问题，因为例如，要向方法添加参数，你必须添加 3 次（后端、代理层和表示层）。

Answer 3

我的第一个问题是：为什么中间有一个 Web 服务？如果这一切都将在同一台物理机器上运行，那么您可能需要重构一个中间层，该中间层通过一组接口使用并使用直接方法调用。

我正在开发一个与中间层 Web 服务分开的架构，但它包含所有公司的关键业务逻辑，并且不会直接暴露在互联网上。比如：

{互联网} -> |DMZ| -> Web 服务器 -> |防火墙局域网| -> 应用服务器 -> 数据库服务器

在这种情况下，我确实认为它增加了一层安全性，因为关键任务的东西不在 DMZ 上。当然，它在技术上仍然违反了一些安全问题，因为 Web 服务器可以联系应用服务器，但是通过单个端口将应用服务器暴露给 DMZ 中的特定 IP 比将其暴露在互联网上要好。

如果您打算使用 WCF 在服务器之间进行通信，我建议使用 TCP 上的二进制序列化之类的东西，而不是 SOAP。那应该表现得更好（随意设置快速测试）。我自己没有尝试过，但 WCF 可能能够通过网络对数据集或表进行序列化。见here。