在同一项目中添加对 WCF 服务的服务引用
将服务引用添加到被引用的服务在同一个 VS 项目中定义的项目中是否是可接受的编程实践？ （服务和服务参考位于同一项目中）
示例：
MyWebAppProj
-服务
--我的服务
-服务参考
--MyServiceServiceReference.MyServiceClient
-Default.aspx.cs 使用 MyServiceServiceReference.MyServiceClient
其背后的原因是可以将 Silverlight 应用程序添加到项目中。如果是这样，我们将必须通过服务层公开所有业务逻辑方法，那么为什么不首先这样做并在各处使用它们以保持网页和 Silverlight 页面之间的标准化。
Is it an acceptable programming practice to add a Service Reference to a Project where the Service being referenced is defined within the same VS Project? (Service and Service Reference are in the same Project)
example:
MyWebAppProj
-Services
--MyService
-Service References
--MyServiceServiceReference.MyServiceClient
-Default.aspx.cs uses MyServiceServiceReference.MyServiceClient
The rational behind this is that a Silverlight App may be added to the Project. If it is, we would have to expose all the Business Logic methods through a service layer, so why not just do that first and use them everywhere to stay standardized between web pages and Silverlight pages.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
我根本不明白你为什么要这么做。
如果您已经与服务位于同一个项目中，那么至少您已经可以访问所有服务/数据合同，所以实际上，调用服务已经非常非常容易。您可以直接使用 ChannelFactory，或者编写自己的自定义 ClientBase派生的客户端代理类（这很简单），在这种情况下您没有理由要添加服务引用。
此外，如果您添加了服务引用，那么您将在同一项目中陷入一堆重复的定义，这没有什么意义（是的，您可以将生成的代码隔离到单独的命名空间中，但仍然如此）。
I can't see why you would want to do that at all.
If you're already inside the same project as the service, at the very least you've already got access to all the service/data contracts, so really, calling the service is already very, very easy. You can either use a ChannelFactory directly, or write your own custom ClientBase<T>-derived client proxy class (which is trivial), there's no reason why you'd want to add service reference in this case.
Furthermore, if you added a service reference, you'd then be stuck with a bunch of duplicate definitions in the same project, which makes little sense (yes, you can isolate the generated code into a separate namespace, but still).