Namespace Naming Guidelines
CompanyName.TechnologyName[.Feature][.Design]
Prefixing namespace names with a company name or other well-established brand avoids the possibility of two published namespaces having the same name.
Use a stable, recognized technology name at the second level of a hierarchical name. Use organizational hierarchies as the basis for namespace hierarchies.
A nested namespace should have a dependency on types in the containing namespace.For example, the classes in the System.Web.UI.Design depend on the classes in System.Web.UI. However, the classes in System.Web.UI do not depend on the classes in System.Web.UI.Design.
Data Contract Design Guidelines
- Avoid namespace conflicts
Name your data contract to avoid conflicts with the application layer. Get used to using the following naming convention for your data contract: EntityNameData, where EntityName matches with the coresponding entity. - No business rules in data contract
The data contract should only define the types allowed to be used by the service, not business rules.The reason that WCF does not support XSD restrictions through data contracts out of the box is that implementing business rules through schema design is an expensive way to implement business rules, because if a rule changes, the schema must be changed, and thus calling clients must be made aware of the change. A better way to implement business rules is within the service implementation itself. This way, changes in business rules do not affect contract designs and services become cheaper to maintain going forward. - Avoid Object Orientated approach
When you design a data contract, you are creating a schema, not an object model. This means that while the entities in your application are likely to use inheritance, this approach does not make sense for the generated schema you are creating. Always review your generated schema using svc to ensure that the contracts create a clean WSDL with clean XSD schemas. - Entity Translator
http://msdn.microsoft.com/en-us/library/cc304747.aspx - Service Interface
http://msdn.microsoft.com/en-us/library/cc304866.aspx - Exception Shielding
http://msdn.microsoft.com/en-us/library/cc304697.aspx
Hosting WCF Service
The service file is copied into an ASP.NET application root in Internet Information Services (IIS), and the assembly is copied into the \bin subdirectory of that application root. The application is then accessible by using the uniform resource locator (URL) of the service file in the application root.
WCF services can readily be hosted within IIS 5.1 or 6.0, the Windows Process Activation Service (WAS) that is provided as part of IIS 7.0, and within any .NET application. To host a service in IIS 5.1 or 6.0, the service must use HTTP as the communications transport protocol.
To host a service within IIS 5.1, 6.0 or within WAS, use the follows steps:
Compile the service type into a class library assembly.
Create a service file with a .svc extension with an @ ServiceHost directive to identify the service type:
Copy the service file into a virtual directory, and the assembly into the \bin subdirectory of that virtual directory.
Copy the configuration file into the virtual directory, and name it Web.config.
The application is then accessible by using the URL of the service file in the application root.
To host a WCF service within a .NET application, compile the service type into a class library assembly referenced by the application, and program the application to host the service using the ServiceHost class. The following is an example of the basic programming required:
string httpBaseAddress = "http://www.contoso.com:8000/";
string tcpBaseAddress = "net.tcp://www.contoso.com:8080/";
Uri httpBaseAddressUri = new Uri(httpBaseAddress);
Uri tcpBaseAddressUri = new Uri(tcpBaseAddress);
Uri[] baseAdresses = new Uri[] {
httpBaseAddressUri,
tcpBaseAddressUri};
using(ServiceHost host = new ServiceHost(
typeof(Service), //”Service” is the name of the service type baseAdresses))
{
host.Open();
[…] //Wait to receive messages
host.Close();
}
This example shows how addresses for one or more transport protocols are specified in the construction of a ServiceHost. These addresses are referred to as base addresses.
The address provided for any endpoint of a WCF service is an address relative to a base address of the endpoint’s host. The host can have one base address for each communication transport protocol. The base address of an endpoint is relative to whichever of the base addresses of the host is the base address for the communication transport protocol of the endpoint. In the sample configuration in the preceding configuration file, the BasicHttpBinding selected for the endpoint uses HTTP as the transport protocol, so the address of the endpoint, EchoService, is relative to the host’s HTTP base address. In the case of the host in the preceding example, the HTTP base address is http://www.contoso.com:8000/. For a service hosted within IIS or WAS, the base address is the URL of the service’s service file.
Only services hosted in IIS or WAS, and which are configured with HTTP as the transport protocol exclusively, can be made to use WCF ASP.NET compatibility mode option. Turning that option on requires the following steps.
The programmer must add the AspNetCompatibilityRequirementsAttribute attribute to the service type and specify that ASP.NET compatibility mode is either allowed or required.
[System.ServiceModel.Activation.AspNetCompatibilityRequirements(
RequirementsMode=AspNetCompatbilityRequirementsMode.Require)]
public class DerivativesCalculatorServiceType: IDerivativesCalculator
The administrator must configure the application to use the ASP.NET compatibility mode.
[…]
That option can save you from having to modify clients that are configured to use the URLs of .asmx service files when modifying a service to use WCF.
Service Development
- Classes or Interfaces (http://msdn.microsoft.com/en-us/library/ms733070.aspx)
- Parameters and Return Values
- Parameters and Return Values
Both classes and interfaces represent a grouping of functionality and, therefore, both can be used to define a WCF service contract. However, it is recommended that you use interfaces because they directly model service contracts. Without an implementation, interfaces do no more than define a grouping of methods with certain signatures. Likewise, a service contract without an implementation defines a grouping of operations with certain signatures. Implement a service contract interface and you have implemented a WCF service.
All the benefits of managed interfaces apply to service contract interfaces:
Service contract interfaces can extend any number of other service contract interfaces.
A single class can implement any number of service contracts by implementing those service contract interfaces.
You can modify the implementation of a service contract by changing the interface implementation, while the service contract remains the same.
You can version your service by implementing the old interface and the new one. Old clients connect to the original version, while newer clients can connect to the newer version.
You can, however, use a class to define a service contract and implement that contract at the same time. The advantage of creating your services by applying ServiceContractAttribute and OperationContractAttribute directly to the class and the methods on the class, respectively, is speed and simplicity. The disadvantages are that managed classes do not support multiple inheritance, and as a result they can only implement one service contract at a time. In addition, any modification to the class or method signatures modifies the public contract for that service, which can prevent unmodified clients from using your service.
A WCF service is provided by defining one or more WCF endpoints. An endpoint is defined by an address, a binding and a service contract. The address defines where the service is located. The binding specifies how to communicate with the service. The service contract defines the operations that the service can perform.