2009-02-09 61 views
2

以前我的ASP.NET Web应用程序连接到数据库直接使用ADO.NET。现在我想将它更改为3层,ASP.NET层,中间Web服务层和后端数据库层。我觉得有益处,我可以抽象数据源到ASP.NET前层,松散耦合和降低潜在的安全风险,让外部暴露ASP.Net Web应用程序,以便能够直接访问数据库等ASP.NET Web应用程序的架构设计咨询

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

  1. 附加的中间web服务层将导致更多的流量,例如, ASP.NET不直接与数据库交谈,而是与Web服务通话,Web服务与数据库交谈,将导致更多流量。它会成为瓶颈吗?任何一般的建议,如果它是一个瓶颈解决这个问题?

  2. 因为ASP.NET无法连接到数据库,但连接到Web服务,它不能很容易地得到一个DataSet/DataTable对象。很难将表格数据提供给数据绑定控件。任何想法使ASP.NET中的表示层更容易编码?

问候,
乔治

回答

8

如果你只认为还有一个好处,你不应该这样做。你在谈论增加大量复杂性并为自己工作,代价是性能,代码简单性和架构简单性,对于......什么?你有什么收获是值得这些成本的?

你:

  • 有需要从数据库服务器断开连接的web前端紧急安全相关的需求(不,不是假设的“我敢肯定,这将是更安全的”,但显而易见的,不能被聪明你授予什么DB权利ASP.NET应用程序)

  • 希望在某个时候完全交换数据层出未来(可能是多次)来解决具体的安全问题,因此需要绝缘您的网页代码库来自激进的DB更改

在几乎所有情况下,这些答案都是否定的。这样做只会给自己和任何可能触及此应用程序的人增加痛苦。

+0

+1 - 如果不需要体系结构就可以获得,请使用该努力使您的前端更好,而不是添加图层 – Brandon 2009-02-09 03:24:42

+0

+1 - 绝对同意这一点。看起来OP会为himeself头痛。 – nickohrn 2009-02-09 03:49:01

+0

雷克斯,你是什么意思“有迫切的安全需要完全断开数据库服务器从Web前端”?换句话说呢? – George2 2009-02-09 04:56:34

1

关于你的问题#2 - 你可以肯定从Web服务返回的数据集。 http://tinyurl.com/ah58xc

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

顺便说一句,在建立多层次的时候,你不一定需要他们最大的危险是,你最终建立“代理”的代码,因为没有更好的术语。也就是说,除了用相同的参数调用“真实”后端方法以外,没有任何其他用途的方法。这种感觉起初更好,因为你有一个干净的图层分离,但会导致维护问题,例如,为参数添加方法,你必须添加它3次(后端,代理层和表示层)。

0

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

我正在研究与中间层Web服务分离的体系结构,但它包含所有公司的关键业务逻辑,并且不会直接暴露给互联网。例如:

{internet} - > | DMZ | - > Web服务器 - > | Firewalled LAN | - >应用程序服务器 - >数据库服务器

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

如果你打算使用WCF在服务器之间进行通信,我会建议使用类似于TCP而不是SOAP的二进制序列化。这应该表现更好(随意设置快速测试)。我自己并没有尝试过,但WCF可能能够通过电线序列化数据集或表格。请参阅here