asmx文件_将Web服务的实现与ASMX文件分开

asmx文件

A fellow said recently that he wanted to build a “monster web service” with over 20 classes and over 20 methods (well, not THAT monster, but not Hello World). He said:

一位同僚最近说，他想构建一个具有20多个类和20多种方法的“怪物Web服务”(嗯，不是那个怪物，而是Hello World)。 他说：

Is there any way to provide my consumers with a single end-point (.asmx) exposing these methods from several different class files? I can’t see my dev team all working on a single ASMX file…what am I missing here?

有什么方法可以为我的使用者提供一个单一端点(.asmx)，以从多个不同的类文件中公开这些方法？ 我看不到我的开发团队都在处理单个ASMX文件…在这里我缺少什么？

It’s easy to make the assumption that the ASMX file has some magic and that everything needs to go in it. But the ASMX is just an endpoint like an ASPX or ASMX. It gives IIS and ASP.NET something to think about, but it’s just a broker – even less – it’s a front.

可以很容易地假设ASMX文件具有魔力，并且所有内容都需要放入其中。 但是ASMX只是一个端点，例如ASPX或ASMX。 它为IIS和ASP.NET提供了一些考虑因素，但它只是一个代理，甚至更少，它是一个前台。

DasBlog has a Web Services interface, thanks to Clemens and the crew before Omar and I, and here’s the contents of it’s EditService.asmx.cs:

DasBlog具有Web服务接口，这要感谢Clemens和Omar和I之前的工作人员，这是EditService.asmx.cs的内容：

That’s it. Seriously. It lives in our main Web Project.  So, how does this work? Well, look at what the class it’s derived from. It’s not System.Web.Services.WebService (yet), it’s EditServiceImplementation.

而已。 说真的它位于我们的主要Web项目中。 那么，这是如何工作的呢？ 好吧，看看它是从什么类派生的。 还不是System.Web.Services.WebService，而是EditServiceImplementation。

RULE: Don’t mix your implementation with your presentation

规则：请勿将您的实施与演示文稿混在一起

A Web Services endpoint is arguably just a presentation of some logic. Hopefully that logic exists somewhere that’s NOT the ASMX file. The ASMX file is just a way to call something somewhere else.

Web服务端点可以说只是一些逻辑的表示。 希望该逻辑存在于ASMX文件以外的地方。 ASMX文件只是在其他地方调用某些内容的一种方法。

For example, here’s part of the source for EditServiceImplementation.cs that’s in a totally different assembly and project.

例如，这是EditServiceImplementation.cs源代码的一部分，它位于完全不同的程序集和项目中。

This shows EditServiceImplementation (remember, NOT in the ASMX.cs file) deriving from WebService. It also shows the CreateEntry method that is marked as a [WebMethod] and exposed to the outside world.

这显示了从WebService派生的EditServiceImplementation(请记住，不在ASMX.cs文件中)。 它还显示了CreateEntry方法，该方法被标记为[WebMethod]并向外界公开。

Note that this method takes an Entry, a username and a password. Internally it checks to see if Web Services are enabled, tries to log the user in then calls the existing .NET API method “SaveEntry“.

请注意，此方法需要一个Entry，一个用户名和一个密码。 它在内部检查是否已启用Web服务，尝试登录用户，然后调用现有的.NET API方法“ SaveEntry ”。

SaveEntry already existed. the CreateEntry WebMethod is a stateless rollup of Login and SaveEntry.

SaveEntry已经存在。 CreateEntry WebMethod是Login和SaveEntry的无状态汇总。

So, in this example:

因此，在此示例中：

WebService Request -> EditService.asmx -> EditService class, deriving from EditServiceImplementation -> Validate the User, etc -> Broker to existing SaveEntry API.

WebService请求-> EditService.asmx-> EditService类，从EditServiceImplementation->验证用户等->代理到现有SaveEntry API。

We leverage the existing dasBlog DataService, we easily create other endpoints (foo.asmx) in a number of ways, the implementation doesn’t even live in the Web Project, and even then, the Implementation is ten lines of code.

我们利用现有的dasBlog DataService，以多种方式轻松创建其他端点(foo.asmx)，该实现甚至不存在于Web Project中，即使如此，该实现也只有十行代码。

Don’t let your [perception] of the  ASMX file cramp your style. You can add a few small layers and not only make development of your Web Service easy, but also friendly for large development groups. Idea: If you’re concerned about collision, folks can test and work on their own atomic endpoints before rolling everything up into one WSDL. Also, remember Contract First.

不要让您对ASMX文件的理解会限制您的样式。 您可以添加一些小层，不仅使Web Service的开发变得容易，而且对大型开发组也很友好。 想法：如果您担心冲突，人们可以在将所有内容汇总到一个WSDL中之前对其进行测试并在自己的原子端点上工作。 另外，请记住合同第一。

翻译自: https://www.hanselman.com/blog/separating-a-web-services-implementation-from-the-asmx-file

asmx文件