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

Question

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

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

1. 额外的中间网络服务层将产生更多流量，例如ASP.NET不直接与数据库进行通信，但是与Web服务进行通信以及与数据库进行Web服务对话会产生更多流量。它会成为瓶颈吗？如果是瓶颈，有什么一般性的建议可以解决这个问题吗？

2. 由于ASP.NET无法连接到数据库但连接到Web服务，因此无法轻松获取DataSet / DataTable对象。将表格数据呈现给数据绑定控件变得很困难。任何使ASP.NET中的表示层更容易编码的想法？

的问候，
乔治

Answer 1

如果你只是认为有一个好处，你就不应该这样做。您正在谈论增加大量复杂性并为自己工作，代价是性能，代码简单性和架构简单性......对于什么？你获得了什么值得这些费用？

你是：

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

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

  < / LI>

几乎在每种情况下，这些答案都是否定的。这样做只会给自己和其他可能触摸此应用的人带来痛苦。

Answer 2

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

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

顺便说一下，当您可能不一定需要它们时，创建多个层的最大危险在于您最终会创建“代理”代码，因为缺少更好的术语。也就是说，除了用相同的参数调用“真正的”后端方法之外没有任何其他目的的方法。这首先感觉更好，因为你有一个干净的层分离，但在未来导致维护问题，因为，例如，要向方法添加一个参数，你必须添加它3次（后端，代理层，和表示层）。

Answer 3

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

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

{internet} - ＆gt; | DMZ | - ＆GT; Web服务器 - ＆gt; |防火墙LAN | - ＆GT;应用服务器 - ＆gt;数据库服务器

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

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