2

以前我的 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 中的表示层更容易编码吗？

问候，
乔治

4

3 回答 3

8

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

你：

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

  • 期望在未来某个时候（可能会重复）完全交换您的数据层，因此需要将您的 Web 代码库与激进的 DB 更改隔离开来？

在几乎所有情况下，这些问题的答案是否定的。这样做只会给你自己和任何可能接触到这个应用程序的人增加痛苦。

于 2009-02-09T03:18:57.523 回答
1

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

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

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

于 2009-02-09T03:38:56.443 回答
0

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

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

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

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

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

于 2009-02-09T03:44:22.500 回答