|
根据功能需求，实现单独的通道来访问你的商业逻辑。
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同他联系。
|
