This project is read-only.

Tier-ing Orchard up?

Topics: Customizing Orchard
Jan 4, 2012 at 5:31 PM

Hi guys,

Not sure if I should ask this here but here goes..

If I need to tier Orchard CMS up into front-end (web) and back-end (logic) and wire them together using xml web services (>1 frontend and 1 backend), could this be done?

Where or how should I go about "splitting" up the system and implementing the webmethod and interfaces?

Should I be doing something like writing a lightweight front-end module that talks to the backend module? Both running on the orchard.core system?

Would really appreciate any help and advice on this...


Thank you very very much..!


(eeks, no preview function?)

Jan 5, 2012 at 4:24 AM

Orchard can use a SQL server as the data repository, and you can have one or more web servers running Orchard that point to the single SQL server to read/write data. There is no xml web service layer involved in between the two however. I'm not sure why that would be a requirement. Maybe if you explain why this is a requirement we can help figure out if it will be possible.

Jan 5, 2012 at 5:35 AM

Hi TheMonarch,

Assuming that the customer is a bureaucrat who has finally "seen" the _advantages_ of having web services (sigh), would it be possible? (Yes, I know it is putting the cart in front of the horse!)

Would it be possible to introduce a web service layer into Orchard using Dependency Injection somehow? So far it looks like a lightweight Orchard installation on the frontend, and a heavyweight Orchard on the back. But I have no idea how to go about this, or if it is even feasible.

Either that, or we will have to go the traditional webform + asmx way.. and throwing away the effort on Orchard so far... (yes, it really doesn't make sense... but...)

Thank you!

Jan 5, 2012 at 8:28 AM

Guess the path to go will be WCF Services, something like

*imagine stretching out right hand behind my head and scratching the left ear* 

Jan 5, 2012 at 9:57 AM
Edited Jan 5, 2012 at 9:57 AM

AFAIK data access in Orchard goes basically through two interfaces: IRepository<> for database-access and IStorageProvider for file access (there is also IVirtualPathProvider, but this should have access to the local file system, e.g. the AppData folder, so changing it to work with a non-local file system is not an option).

So you could do this:

  • Have a very basic Orchard installation in the backend, with only one (non-core) module, a web service that exposes an interface that can do everything the mentioned two interfaces promise.
  • Have an Orchard installation in the frontend where you have one module that provides implementations for these two interfaces (and suppresses the built-in ones) that use the backend web service.

This is the most straightforward I think. However I see no gain in such an architecture besides being a magnitude slower, even if the frontend and backend servers are on the same network :-).

It seems that you want to do something along the lines of a thin client architecture - but why would you do that if you have a web application?

Jan 5, 2012 at 1:35 PM

I think you are better off trying to convince the client not to try such an architecture, or maybe you should consider passing on this project. What you are asking would introduce unnecessary complexity and potential performance issues.


If you want to scale out the front end, just add more web servers, and use caching. 

Jan 5, 2012 at 8:47 PM

I smell buzzword-driven management in here (buzzwords from 10 years ago actually). Maybe throw some acronyms and cool "new" buzzwords at him, so he can look even cooler to the CEO.

CMS, jQuery, ORM, D-VCS, Composition, Convention over Configuration, IoC, DI come to mind. That should keep him busy for a couple of weeks.

You can see the tongue in my cheek from where you're standing I assume.

Jan 9, 2012 at 9:51 AM

Hi Peidone, TheMonarch and Betrand,

Thank you for the suggestions. I have tried to dissuade them from hacking the framework up this way but the unknowledgeable PM there insisted on having 3-tiers wired up via web services. 

I will most likely setup 2 orchard instances (one for web, one for app) to satisfy the requirements. 

Bertrand, I threw ReST and JSON at them, it fell on death ears... they don't know anything about it and all they could say was "As the consultant, we expect you to give us recommendations on the technology... but we want a 3-tiered architecture...". 

So... now I am reluctantly mapping out the interfaces where I have to split the modules up... sigh. Yes it is a horrible horrible thing to do worthy of mention in The Daily WTF but they insist on having it, muttering things like "security" and "load balancing" at me throughout our meetings. 

Thank you once again, my only hope is they will balk at the additional man-day charges... 

Jan 9, 2012 at 1:56 PM

"3-tiered architecture" can mean many things and Orchard happens to be an MVC app which is itself a 3-tiered architecture. Of course you could look at it as many more tiers than that, and exposing a complete web service layer simply adds yet another tier. Whether they need that tier or not depends on their exact use cases...

Jan 10, 2012 at 1:30 AM

My conspiracy theory on the whole 3-tier with web service approach is that it's a hoax perpetrated about 10 years ago by the companies behind the failed WS-X standard stack, that aimed at selling their crap to unsuspecting companies that have been paying dearly for it ever since.

Jan 19, 2012 at 6:28 AM

I just came across this and had to chime in. :)

I perceive a lot of value in service orientation and WCF specifically (which absolutely is NOT just about web services).

Now, before I get flamed, I absolutely don't see a need to break Orchard itself into more tiers, it's a fantastic system and I love the architecture. For any amount of scalability you just deploy to a web farm - from what I have seen in the code, if you run into performance issues they absolutely won't be caused by Orchard. If the single database behind Orchard is a bottleneck then there are ways to fix that as well with or without service orienting the data layer.

Tiers and scalability are IMO only a very small part of why the choice of service orientation should be made (specifically WCF).
Study Juval Lowy's book "Programming WCF Services" and you'll get the idea - WCF isn't about web services, it IS the new .NET.

Should mean a LOT to say that part of the CORE of the next Windows OS is built ON WCF (though I don't think it's being called WCF in that context).

Also, most develorers don't realize that almost ALL "3-tier" architectures are really just one fat tier split across multiple assemblies. :) If your database has a User table with FirstName and LastName and your data access layer exposes a single method named GetUser that returns a user dto with FirstName and LastName and your UI has a form with a "Get User" button that displays the labels FirstName and LastName well, argue as much as you'd like but you really have only 1 tier. Go change FirstName in your database to FName and tell me how well your application runs without refactoring the other two "tiers". ;)

Or even better, remove FirstName from the database completely, because you no longer need it. Consider it a litmus test. If you get an error in yor UI, you probably don't have a true n-tier architecture. The whole point about tiers to to allow each the chance to interpret the data AS THEY WANT TO, not just funnel the data up to the next tier. If all you are doing is piping the data verbatim from the database through the DAL to the UI then you really don't need the DAL - it's not serving you any real purpose.