2016-02-19 64 views
0

我习惯于看到如下的n层设计模式: 1)数据库(SQL Server) 2)域(EF) 3)Facade Service Layer(WCF ) 4)MVC的Web应用程序(IIS)N层设计中的Web API C#

在防火墙方面和保护区,Web服务器和MVC应用程序住在一个Web服务的前一个面向公众的区(DMZ),是生活背后的另一个防火墙处理业务逻辑并连接到数据层,以增加一层安全性。

在防火墙(而非DMZ)后面使用Web API将业务逻辑传回网站是否有任何理由或优势?我认为这是WCF擅长的地方。

例如,如果创建了本地移动应用程序并且需要访问服务器,那么其他WebAPI Web服务是否将存在于DMZ中(类似于MVC站点),然后再连接回内部服务(WCF)是否回到业务逻辑处理?我确定它取决于应用程序的特定需求,但作为一般设计模式,Web API应该在体系结构的哪个区域生存?

谢谢!

+0

如果您的WebAPI正在提供数据以供客户端使用,它可能与MVC代码位于相同的位置,很可能在同一个实际项目中。您将拥有MVC和WepAPI控制器。 – Mant101

回答

0

您应该使用没有“通用设计模式”。什么会消费Web API?是否只是在内部消费,如果是这样,然后隐藏它,只允许访问需要它。

Web API的主要优点之一是不同客户端的负载可以消耗它,例如SPA,Mobile,其他服务器等等。因此它们通常是公共的,并且正如Mant101所说的那样,他们很多时间都活着在与您的MVC实现相同的项目中。

比它住的地方更重要的是你可能如何保护它?应用程序/用户将如何验证自己?我个人会考虑这个,而不是DMZ。

如果您要使用类似OWIN中间件的东西,那么您可以为此API提供不同的身份验证方法,以便它可以被移动设备等使用。如果你真的想维护N层的东西,你可能会以某种方式代理API,但试图用网络设计而不是应用来解决它。

+0

身份验证将使用AspNet Identity 2.0完成。将业务逻辑放回单独的应用程序服务器的概念被提出用于额外的安全层。前面是一个MVC Web应用程序。之后,移动用户可能会出现这种情况。所以......它会有MVC - > WCF(Web Api)。后来可能是Web Api - > WCF(或Web.Api) – user3900102

+0

@ user3900102我觉得更像是将整个应用程序包装在OWIN中间件中,或者像你现在拥有WCF的地方,然后你可以使用不同的安全选项为不同的消费者。使用反向代理等功能在DMZ中发布服务。 MVC和API都是ASP.NET服务器为什么要链接它们? – jolySoft