.NET distributed layered application

Question

I have been developing n-tier applications using .NET for many years. But I still have no idea how to distribute the tiers/layers (dll) to other servers.

Let say, I have an MVC web application with 4 projects, ie MVC (UI), Business, Service and Data. Everything works fine if all class library dlls are in one server.

If I want to scale out the application by distributing the Service layer (dll) and Data layer (dll) to other 2 servers, should I convert the class library to WCF Service Library project (with TCP or pipe as communication protocol for better performance) ? Or should I use other technology like .NET remoting or Web API?

Will that be a lot of work?

Is that one of the purpose of creating multi-tier application?

Thanks.

Update:

Do you have any links (from Microsoft) that explain in detail how to scale out an n-tier architecture application to multiple server by distributing the DLL?

Answer 1

If I want to scale out the application by distributing the Service layer (dll) and Data layer (dll) to other 2 servers, should I convert the class library to WCF Service Library project (with TCP or pipe as communication protocol for better performance) ?

Yep, since they are on different machines, you need some kind of communication mechanism that goes beyond simply DLL invocation.

Or should I use other technology like .NET remoting or Web API?

Which approach you choose depends on many factors like complexity, performance...There are many options like

• WCF webservices
• Simple REST calls with WebApi
• a message bus ie NServiceBus
• ...

Obviously remote calls will also be slower having a potential impact on performance etc.

Will that be a lot of work?

It will be more work and in my opinion that "more work" should really be justified. Keep your architecture as simple as possible or better, only as complex as really needed.

An alternative approach could be to have some deployment pipeline that deploys your entire application on different server instances and have some intelligent load balancing strategy. The only thing you need to pay attention to in that case is to properly share the sessions between your instances (stateless would be better ;) ).

Answer 2

My 50 cents... As far as I know WCF replaced .NET Remoting ( MSDN ).

Anyway... Someone before me said. If you don't have to scale the application, do not do it. Communication cost alone between services of any kind will slow things down considerably. Probably to extent, where it would be slower than it is now (which I am assuming is the reason for scaling).

Prior to scaling, I would first see where the bottleneck really is. For instance, if the problem is your DB server, then moving services and data layer to another server is useless, as you will still be using the same database. So, you need to first find out what your bottelneck is.

The easiest and least painful way to scale (in my opinion) would be to just add another IIS server and a load balancer that would direct traffic to either one of them. You would need to store sessions in a database or use dedicated server, but that is about all the change you will need. Plus, if one of your server fails, one will still operate.

Answer 3

By default, avoid premature optimalization.

If you have a only web site, I would keep it as simple as possible and only create logical layering. There are a number of options: typical 3 tier, onion architecture etc. The key is that later, if really really needed, you could still refactor your code and make your data layer a separate physical layer. But unless you are creating a new Amazon or something, this will probably not be the case.

If you are in the situation, for example, that you have a web site, but also have to expose a web api; you could choose to have the web site consume the web api. In fact, your web site would then become a very thin layer (maybe not even using ASP.NET MVC) because most of the logic would be in the web api.

PS - .NET remoting is old technology , consider WCF or Web API instead.