首页/技术开发/内容

创建Web Service Storefronts

技术开发2022-09-15 阅读()
根据功能需求,实现单独的通道来访问你的商业逻辑。
by Jonathan Goodyear, MCSD, MCP, CLS
大多数商业应用程序只通过Web services给外界提供其功能的一小部分。大多数应用程序的商业逻辑都是在企业内部互联网中的防火墙后的。而且,在外部和内部,你总是需要同样的功能。理想情况下,你不需要在两个不同的地方编写这个重复的功能——它应该保留在一个集中的商业逻辑层中。要实现这一点,一种方法就是实现多个Web service接口,将它们作为进入你的商业逻辑的通道。我把它们称作Web service “storefronts”。

例如,假设你在为一个网站构建一个内容管理应用程序。在内部,你可能需要一些功能来增加、更新、删除和读取网站内容。如果你允许其它的网站运用你的内容,那么在外部你只需要提供读取功能。为了适当地封装你的商业逻辑,你需要将所有这些相关的内容部件功能添加到一个叫做ContentWidget的单独的集合中(见列表1)。

接下来,你创建两个单独的Web service接口,叫做InternalContent和ExternalContent。这两个Web services都会引用ContentWidget集合。InternalContent Web service为ContentWidget.Server对象提供了每个方法,因为你(大概)需要所有这些方法来管理你的网站的内容(见列表2)。

然而,ExternalContent Web service将只提供GetContentWidget方法来读取内容,因为对你的网站的内容的外部访问目的是单一的(见列表3)。注意,InternalContent和ExternalContent Web services都实现了GetContentWidget方法。如果你知道你的内容管理应用程序有权限访问这两个Web services,你就可以从InternalContent Web service删除GetContentWidget方法,作为替代,你可以调用ExternalContent Web service来读取内容,从而就可以删除所有的多余的代码。然而你的内部应用程序并不是总是有权限访问这两个Web services的。

Web services storefront方法的好处就是你可以集中所有的商业逻辑,同时也可以控制你给外界提供的功能。需要记住的一个主要的概念是Web services不能用来提供商业逻辑。它们就类似一个ASP.NET Web应用程序中的Web窗体。它们只是方便了不同系统间(或人们之间,在Web forms的情况下——见资源)的交互。确信将IIS验证添加到InternalContent Web service,以便限制已提供有效安全属性的应用程序对它的访问(见资源)。

你也可以用.NET remoting实现同样的Web service storefront方法。到你的商业逻辑的内部接口和外部接口是分离的,所以你可以同时实现它们。在这个例子中,我选择在内部和外部都运用了Web services,因为在这种情况下,你的商业逻辑集合就有很好的机会可以与非.NET系统交互。遇到一个.NET remoting应用程序并与之交互的可能性是很细微的(就目前情况来说)。

下载Web services storefront的一个完整的样例。它包含ContentWidget商业逻辑集合、两个Web service storefront项目、一个ASP.NET Web应用程序、安装SQL Server表的脚本和存储、管理内容数据的存储过程。


关于作者:
Jonathan Goodyear是ASPSoft(www.aspsoft.com)的总裁,这是个位于Orlando,Fla.的一家Internet咨询公司。他是位MCSD,是Debugging ASP.NET(New Riders)一书的作者,你可以在www.debuggingasp.net找到它。你可以通过jon@aspsoft.com与他联系,或者通过他在www.angryCoder.com上的angryCoder eZine同他联系。

……

相关阅读