Hosting presentation layer and application layer on different servers

Question

My presentation layer encompasses an MVC pattern and the application layer includes services and DTO's, all of which uses the ASP.NET framework.

The idea behind splitting the code up like this was to make it possible to host the presentation layer on one load balanced cluster of servers and the application layer on another cluster of load balanced servers.

We don't want to have to serialize the data between servers, and would prefer to be able to activate the classes and invoke the methods in the application layer as if they were part of the application which makes up the presentation layer.

I can't find any documentation on how to implement such a setup nor can I find out what the name of such a setup would be so I am struggling to get started. Is what I'm trying to achieve possible?

Answer 1

Your first challenge will be to connect your presentation and service layers. It should be pretty painless to expose your service layers using Web API or SOAP. You could even use Windows RPC or DCOM, though I suspect this might be invasive and force changes to your service layer code.

When you do this you'll be introducing an extra network hop and marshalling/unmarshalling of your data (as objects are converted to string representation and then converted back to objects after transmission on the network), Depending on your app this may not make any difference at all, but it's something to keep in mind.

You also need to solve the problem of how to scale. The most usual approach here would be to introduce two load balancers, one for the front and and another for the back ends. Scaling and adding another layer of complexity.

A more modern (simpler and more performant) approach might be to organize your app as a set of micro-services. You'd deploy a silo of your apps functionality (say user management or user preferences) and package and deploy your user service, DTO, and your presentation controllers together. You can then deploy scale each slice of your application individually (and get native performance within each slice).

This approach really starts to shine as you move your controller logic into the client (the web browser). A single client talking to a multifarious backend via REST.

If you don't, if you template on the server in classic mvc.net fashion, then the microservices approach becomes less elegant. At the very least, you have to solve the problem of distributing common template assets (css, js, images) across multiple deployables. It's not a huge problem, but you'd probably need to make this part of your build process. Also you'll have to consider what happens when you change these assets. Will you need to redeploy all of your full stack microservices?

Answer 2

You could use WCF...

The idea behind WCF is to allow you to implement the effect of server-side classes exposed over a network connection.

You define your interfaces with their properties and methods, build out their server-side implementation, and on the client side of the implementation, have Visual Studio auto-generate an API for you.

You can use WCF over TCP/IP or HTTP connections (not sure if TCP/IP lends itself to load balancing/scaling). TCP/IP is obviously intended for connectivity between machines on the same LAN and I believe carries less overhead than HTTP. WCF also works over named pipes, but that is for process to process communication on the same machine - not relevant here. In any case, there is still a serialization process no matter which protocol you use; for HTTP it will be SOAP (somewhat heavy); not sure about TCP/IP.

I have successfully implemented solutions using WCF over TCP/IP, HTTP, and named pipes, but scaling was never a consideration for any of them.

For most purposes, I am moving away from WCF now in favour of RESTful .NET WEB API 2 services, using JSON as the serialization format. Consuming them may be a little more work than with WCF, but it's much easier to set up on the server side.

Addendum:

I should add a benefit for the RESTful WEB API approach: flexibility. Today you don't want the client browser to process javascript, but if that should change, you won't have to make any changes to the application server. The change would be limited to your presentation server offloading processing from itself to the browser. If you pick an RPC approach (like WCF), you have a bigger commitment to that architecture and lose the flexibility to easily move away from it.