Question

我们需要将当前驻留在ASP.NET应用程序中的某些服务（即AddressValidatorService，CustomerFinderService）公开给组织内的其他应用程序。通过WCF公开这些服务似乎很自然，但是我没有看到任何关于如何将这些公共服务引入WCF包装器的最佳实践，这样我现有的ASP.NET应用程序可以继续使用它们。代码更改和/或意识到他们正在消费的服务不再在进行中。

我特别关注如何构建现有ASP.NET解决方案的建议，以及是否在我们的ASP.NET应用程序和外部调用者引用的同一解决方案或一些新的共享WCF解决方案中托管我们的新WCF。

另外，简单地将目前仅通过ASP.NET进行过程中的DTO推广到完全成熟的数据合同或是否最好创建使用[DataContract]明确修饰的重复DTO是不好的做法？后者似乎是一场维护噩梦。

Answer 1

回答你的第二个问题：

另外，简单地将目前仅通过ASP.NET进行过程中的DTO推广到完全成熟的数据合同或是否最好创建使用[DataContract]明确修饰的重复DTO是不好的做法？后者似乎是一场维护噩梦。

将业务模型公开为WCF合同被视为不良做法。因此，如果您的DTO是您的域模型的副本，那么这将是一个严格禁止，因为
1.模型的任何变化都会直接影响合同，因此所有客户都会使用它 2.你将把你的业务“技术诀窍”暴露给外界。

对于任何不断发展的系统来说，后者可能会变得困难，但是你会有各种开源工具（比如AutoMapper），可以简化你的映射工作。

Answer 2

您可以将现有项目转换为WCF，然后使用项目引用继续在进程中使用它。然后，它可以由使用WCF客户端的永久源使用。当通过WCF使用时，WCF客户端将类名称从ClassName转换为ClassNameClient，但该类的功能几乎相同。

例如：

MyClass obj = new MyClass();
obj.DoSomething(withData);

会变成：

MyClassClient obj = new MyClassClient();
obj.DoSomething(withData);

您可以将WCF项目发布到某个端点，例如address.example.com，然后使用对端点的服务引用来引用其他项目中的代码，如项目引用。

请注意，虽然外部引用项目不会受到更改的影响，或者知道数据是通过网络传输的，但如果您对相关项目进行了繁琐的调用，那么它肯定会受到性能影响。您可能希望将相关方法合并为单个方法以节省往返。

Answer 3

如果它们作为静态页面服务公开，那么就没有神奇的包装器 - 您需要将代码移动到独立的服务实现类并将.svc文件放在它前面。（或者使用WCF4无文件激活或服务工厂，但这里的核心问题有点远。）

如果这些是作为ASMX公开的，您实际上可以将ASMX外观置于WCF服务类的前面，并获得基本的HTTP / XML / ASMX响应，就像从旧的ASMX Web服务中获取一样。您可以通过标准WCF配置为非传统使用者公开相同的WCF服务类。

最后，您可以使用serviceMetadata + httpGetEnabled将任何WCF服务公开为basicHTTP，并且您将获得ASMX服务的旧版用户可以使用的服务端点。

http://msdn.microsoft.com/en-us/library/ms751433.aspx

从现有ASP.NET应用程序创建/公开WCF服务

3 个答案: