我正在尝试在Windows服务上托管WCF服务。基本上WCF服务从同一台机器上的后端数据库读取数据。现在从同一台机器上的ASP.NET服务器,我想读取数据那个WCF服务已从Database中读取。任何人都建议我采用正确的方法来做到这一点?还有必须用于相同的绑定。
答案 0 :(得分:1)
根据我的理解,你要做的事情是这样的:
ASP.Net App - > WCF服务 - > DB
应用程序调用WCF服务上的方法,该方法从数据库中读取一些数据并创建报告并将其发送回应用程序。如果这是意图并且app和service都在同一台机器上,那么你可以使用命名管道绑定,这是非常快的,并且是同一台机器上系统的首选通信方式。您还可以使用更具可伸缩性的http绑定。但是WCF框架的巨大优势在于您可以轻松地更改绑定而不会影响功能。所以,我建议你使用命名管道(net.pipe://),然后根据需要切换到Http。
答案 1 :(得分:1)
从您的评论中可以看出,您的目标是让同一个WCF后端提供不同的UI。以下是关于绑定的一些信息:
要在同一台计算机上访问WCF服务,最佳绑定将为named pipe binding。但是,无法从其他计算机访问命名管道绑定。
如果您必须从其他计算机访问该服务,您应该转到TCP Binding。请注意,命名管道和TCP绑定都将仅从.NET客户端使用(这不应该是您的问题)。
最后,如果您必须通过互联网公开服务和/或他们需要互操作,BasicHttpBinding或WSHttpBinding可能是您的选择。但是,我会为内部/私人消费和外部/公共消费提供不同的服务接口。
最后,您可以通过配置轻松更改绑定,因此您可以选择名称管道来开始,并可能在将来将其更改为tcp绑定。此外,它可以在具有不同绑定的不同端点上暴露相同的服务。
现在,到目前为止托管WCF,您可以在Windows服务或IIS中托管它。 IIS的优势在于您拥有经过测试的可扩展主机,可通过UI提供相当少的管理选项。另一方面,使用IIS(作为Web服务器),您不能使用命名管道或tcp绑定。使用较新的Windows服务器,您甚至可以借助WAS(Windows激活服务)消除这种不利之处。
最后,您是否考虑过使用常见的进程内层而不是WCF之类的进程外层?例如,您可以拥有一个公共库(或一组库),它们可以提供具有清晰API的业务逻辑/数据访问。相同的库可以在不同的UI中使用,例如ASP.NET和窗体 - UI必须使用接口和工厂(或DI框架)来访问该层。优点是,您可以通过进程内调用获得性能提升。另一方面,使用进程内层的桌面客户端无法轻松扩展或无法通过Internet使用。基于WCF的应用服务器解决了这些问题。我更喜欢创建将在基于服务器的UI(如ASP.NET)中使用的进程内层,而基于客户端的UI在同一进程内层使用WCF外观。
答案 2 :(得分:1)
使用WCF只是为了保持代码分离,以防您希望或需要使用其他UI,这不是很合乎逻辑。您可以做的是将所有逻辑写入单独的程序集中。在WCF中实现它时,您最终会这样做。 WCF只是一个托管框架,将在进程外主机中托管底层程序集。如果您拥有该服务的单个使用者,并且您希望将其托管在同一台计算机中(如在帖子中),则可以在进程中使用它。您的代码隐藏代码可以引用单独程序集中的数据访问类。与通过代理访问WCF服务时相同的事情。