0

What is the benefit to keep the WCF project having - WEB HOST PROJECT and Service Implementaiton project separately.

  1. Service contract library
  2. Service implementation library
  3. Service Host project

I understand Contract and Implementaiton to keep separate will helpful for SOC principal and allow to use into other application also if require to implement interfaces.

But,I am not understand why to keep - Service Host and Service Implmentation project separately.

I went through below link, but not understand the benefit of keeping this separate. http://www.devx.com/codemag/Article/39837 (Page 4,5)

If any one guide here then, it is helpful.

Thank You

Konrad Kokosa
  • 16,563
  • 2
  • 36
  • 58
user3711357
  • 1,425
  • 7
  • 32
  • 54
  • It allows you to test service implementation (its logic) by unit tests. All service dependencies should also be injected, to make those test independent from real components. Hosting service is then only a infrastructure topic. – Konrad Kokosa Jul 03 '14 at 13:39
  • we would also achieve this by adding service project reference into Unit test project and call - implemented method.... we do have contracts as well. – user3711357 Jul 03 '14 at 13:48
  • Somewhat yes, but this would be also test depending on the WCF self hosting implementation etc. which is completely not important in testing service logic. And it makes dependent how it will be hosted, it not must be WCF. – Konrad Kokosa Jul 03 '14 at 14:18

2 Answers2

3

As the article said:

Decoupling the services from the host lets you host your services in whatever type of host you want, and to change that host any time. Now, the host could be an IIS application, Windows Activation Services, or any self-hosting application including console applications, Windows Forms applications, Windows Services, etc. - WCF the Manual Way…the Right Way : Page 3

Test mocking, though important, arguably applies to most things programming wise. What is more useful here however is how service separation helps to deploy said services in production, not how it helps developer-level testing. The latter is only useful for a short time period compared to the operational life of the system in production where operations staff may change how the service is hosted. Operations, from an ALM perspective, continues way after SDLC completes.

Though off topic here, one can go further and decouple service logic itself not only from the service's contract but also from anything WCF-related. As mentioned in Thomas Erl's book SOA Design Patterns -

Facade logic is placed in between the contract and the core service logic. This allows the core service logic to remain decoupled from the contract. - Service Façade

  • Keeping the WCF implementation and WCF host process separate allows you to change how it is hosted later
  • Advanced: Keeping the WCF implementation and service processing logic separate ensures the latter is free to change without impacting users of the exposed service contract
  • Ok, Understand, can you tell me, how to add service reference into client project when `service host` project is separate then implementation ? For now, when i try then it gives me following error `The type 'ServiceProject.Implementation.Service1', provided as the Service attribute value in the ServiceHost directive, or provided in the configuration element system.serviceModel/serviceHostingEnvironment/serviceActivations could not be found.` – user3711357 Jul 03 '14 at 14:39
  • It looks to me you may have attributed your service incorrectly when **Add Service Reference** is trying to reverse engineer your WSDL. This is perhaps all moot since you according to your OP, should not be doing this. If you follow [WCF the Manual Way…the Right Way](http://www.devx.com/codemag/Article/39837), as you mentioned, then you don't use Visual Studio **service references** at all - you add a **project reference** to your **contracts assembly** and another to your **client proxies assembly**. You **don't** add a reference to the service host; implementation; or service facade. :) –  Jul 03 '14 at 15:03
0

In addition to Micky's answer, I give you some examples of deployment. 1. If you are going to host the service in IIS, you don't need the Service Host project, since IIS/WAS/.NET runtime will created a service host for you upon the first client request. 2. If you want to host the service in Windows service or a console app, you may create the service host in the Window service project or the console application project, because there will be just a few lines of codes for creating Service Host, unless you have complex logic of managing service host.

ZZZ
  • 2,752
  • 2
  • 25
  • 37