Hosting the presentation layer and the application layer on different servers

advertisements

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?


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?