WCF, why make it more complicated? [closed]

Question

today i have a question regarding style of WCF communication.

I sometimes refuse a bit so use things programmatically (want to have control myself) and I don't like huge. Sometimes communication between 2 program parts are needed, sometimes on the same machine, sometimes on network.

So I tried to use WCF programmatically instead of using configuration files, svcutil and so on.

If I use the following:

a) Define a contract

[ServiceContract]
    public interface IMyContract
    {
        [OperationContract]
        bool DoSomething(string something_in);
    }

b) programm some code

public class MySomething: IMyContract
        {
            public bool DoSomething(string something_in)
            {
                if(String.IsNullOrEmpty(something_in)
                      return false;
                return true;
            }
}

and then programmaticly host it

Uri baseAddress = new Uri("net.tcp://localhost:48080/MySimpleService");

            using (ServiceHost host = new ServiceHost(typeof(MyContract), baseAddress))
            {
                host.AddServiceEndpoint(typeof(IMyContract), new NetTcpBinding(), "");
                host.Open();

                Console.WriteLine("<Enter> to stop the service.");
                Console.ReadLine();

                host.Close();

and later just consume it from another program:

var binding = new NetTcpBinding();
            var endpoint = new EndpointAddress("net.tcp://localhost:48080/MySimpleService");
            var channelFactory = new ChannelFactory<IMyContract>(binding, endpoint);

            IMyContract client = null;

            try
            {
                client = channelFactory.CreateChannel();
                bool test = client.DoSomething();
                ((ICommunicationObject)client).Close();
            }
            catch (Exception ex)
            {
                if (client != null)
                {
                    ((ICommunicationObject)client).Abort();
                }
            }

what would be the drawback?

Wouldn't it be easier to understand?

Could such a thing cause other problems?

(I'm mostly interested in this, because I think it is quite annoying to use svcutil and so one just because of a class change, which can simple handled manually, if the wcf service is only used for cumminication of own programs) So what am I missing?

Is it just a bad style to do things manually instead with large unread XML files?

Answer 1

Your question can be divided into multiple parts:

Is it OK to hard code address?

NO. In the same way we don't hard code connection strings we also don't hard code paths to resources or services (at least not absolute paths). You never know when you would need to change it for any reason - for example to test a new version of the service. Use at least simple app settings if you don't want to use full endpoint configuration.

Is it OK to hard code binding and configuration?

If you don't expect to change it very often and if you are happy with recompiling and redeploying server and client every time you change it you can hard code it. The API provides this because it is valid use case.

Is it OK to share service contracts and data contracts between client and server?

Again it depends on the way how you expect the application will grow and how you expect complexity of deployment. Sharing assembly is valid use case if you have full control over both client and server code but you must remember that it introduces tight coupling between your server and client application. Svcutil is tool which helps you generating clients from SOAP services you don't have control over (you don't have their code or they are not written in .NET) or for clients where you want to follow loose coupling with a server.

I very often use configuration with shared contract assembly myself = no svcutil.

Edit:

Anyway there is no technical drawback in coded configuration over XML configuration (some advanced configuration are even not available in XML). If a developer knows WCF he would understand both XML and code. If developer doesn't know WCF he would probably be more satisfied with the code because XML configuration may be hidden from him for a while.

Answer 2

It should work fine to do this programmatically. The main issue arises when you want to change something, or if an end user is required to change something. If the endpoint address or other config will change, it will be much easier to not have to recompile the code.

I would say that it would work out better to use a config file, that way the setup is kept in a separate place, and is easy to find when it's needed.

I would only opt to hardcode the config if you have good reason to want to hide it from the user (eg, you don't want them to see it/mess with it).