WCF Service Layer in n-layered application: performance considerations

Question

When I went to University, teachers used to say that in good structured application you have presentation layer, business layer and data layer. This is what I heard for more than 5 years.

When I started working I discovered that this is true but sometimes is better to have more than just three layers. Two or three days ago I discovered this article by John Papa that explain how to use Entity Framework in layered application. According to that article you should have:

• UI Layer and Presentation Layer (Model View Pattern)
• Service Layer (WCF)
• Business Layer
• Data Access Layer

Service Layer is, to me, one of the best ideas I've ever heard since I work. Your UI is then completely "diconnected" from Business and Data Layer. Now when I went deeper by looking into provided source code, I began to have some questions. Can you help me in answering them?

Question #0: is this a good enterpise application template in your opinion?

Question #1: where should I host the service layer? Should it be a Windows Service or what else?

Question #2: in the source code provided the service layer expose just an endpoint with WSHttpBinding. This is the most interoperable binding but (I think) the worst in terms of performances (due to serialization and deserializations of objects). Do you agree?

Question #3: if you agree with me at Question 2, which kind of binding would you use?

Looking forward to hear from you. Have a nice weekend!

Marco

Answer 1

Question #0: is this a good enterpise application template in your opinion?

Yes, for most middle-of-the-road line-of-business applications, it's probably a good starting point.

Question #1: where should I host the service layer? Should it be a Windows Service or what else?

If you're serious about using WCF services, then yes, I would recommend self-hosting them in a Windows service. Why? You don't have to have IIS on the server, you don't have to rely on IIS to host your service, you can choose your service address as you wish, and you have complete control over your options.

Question #2: in the source code provided the service layer expose just an endpoint with WSHttpBinding. This is the most interoperable binding but (I think) the worst in terms of performances (due to serialization and deserializations of objects). Do you agree?

No, the most interoperable would be a basicHttpBinding with no security. Any SOAP stack will be able to connect to that. Or then a webHttpBinding for a RESTful service - for this, you don't even need SOAP - just a HTTP stack will do.

What do we use??

• internally, if Intranet-scenarios are in play (server and clients behind corporate firewall): always netTcp - it's the best, fastest, most versatile. Doesn't work well over internet though :-( (need to open ports on firewalls - always a hassle)

• externally: webHttpBinding or basicHttpBinding, mostly because of their ease of integration with non-.NET platforms