I need to implement a printing service that would work on an internal network (an android device is also part of the network).
It is currently implemented by a TcpListener which accepts connection requests (in JSON format), when a request is received its stream is read into a string and deserialized with JsonConvert class.
I got the impression that using WCF should be preferred over a TcpListener for most operations where performance is not critical, but is it true even for such simple scenarios?
Even with TcpListener all I needed was just to get the request stream and deserialize it which doesn't seem like too much of a hassle, should I still prefer WCF for this?
WCF allows your code to stay focused on your business logic, not transport mechanisms and serialization/deserialization.
Right now, your only need your service to accept TCP connections, deserialize the received JSON data into your objects, and pass those objects to your business logic. For argument's sake, you next decide to add a second service. You add logic to parse the HTTP header and choose the appropriate business method to call. For this second service, you also need to support read (HTTP GET) and write (HTTP POST). After a while, you realize you're writing a custom HTTP server.
Let's say a year from now you make a deal with another company who wants to call that service over SOAP, or using a message queue, or some other mechanism. Do you want to refactor your code? In theory WCF allows you to make a change to a config file exposing a new endpoint.
WCF is a complex beast and not trivial to learn. More recent versions have added some shortcuts to make our lives easier. For a simple self hosted JSON service it isn't that hard to set up. Here are a couple of things to read to get you started: