This project is read-only.

Orchard for Complex Applications

Topics: Customizing Orchard, General, Writing modules
Aug 6, 2013 at 2:18 AM
I would like to know what the success story looks like for using Orchard CMS for complex web applications. It would seem that this product is an excellent and flexible fit for any of the brochure-ware sites that you can imagine. With the ability to extend using custom built and download modules the possibilities are endless.

The story does not seem so clear for web applications. I have looked on many forums and there appears to be a reasonable split on opinions:

To use Orchard for Web application would mention the following:
· A lot of the content you will write for an MVC application comes out the box in Orchard allowing a reduced time to market
· For application with a fluid set of requirements and functionality, Orchard offers a good choice here as there is a reasonable chance that the problem has been attempted by someone in the community, or you can develop your own

Those against Orchard for web application would mention the following:
· It’s a content management system, web applications do not have any content to manage and therefore this tool should not be used
· You have to learn how Orchard does it before you start. I have already learnt the MVC stuff and this offers a reduce start-up cost

I am also interested in how an web application in Orchard might look like in terms of best practice with creating modules. There are postings on stack overflow ( this one for example ) that identify how in include your application in Orchard but this would not offer any of the Orchard agility in terms of styling and moving widgets.

Hope this makes sense and look forward to your response.
Aug 6, 2013 at 10:47 AM
Define "Complex".... The problem is that one persons complex website is another persons simple website.... With that I can give you some examples..

The John Varvatos produced by Onestop is hooked directly in to a massive ECommerce system

The Bath Spa University website Registers student for both Accommodation and for the university. This is hooked in to Finance systems Work Management Systems, internal Active directory to create student accounts - you wouldn't believe how much stuff its actually hooked in to.

nwazet (Bertrands Company) I think is hooked in to Shipping gateways and Payment Gateways, something he has previously described as One Tough Mother!

Remember what looks like a "Brochure-ware" site from the UI, does not necessarily mean that its not a complex system
Aug 6, 2013 at 2:48 PM
Edited Aug 7, 2013 at 5:10 AM
Thank you for this response, it is a fair challenge to ask what is complex. Let me defined this further (in the spirit of how this question was originally posed).

It would seem that Orchard is well suited to define brochure-ware sites where for arguments sake you would define content types, define layers and rules for their display. This may involve interaction with web services but all of this functionality is contained within Orchard and it's defined modules.

Contrast this with a more complex example. I would like to create a web application which will be written using MVC (great news). I realise that the majority of the functionality is already available within Orchard (authorisation and authentication. Multi tenancy, etc.), but now I have a design decision to make. Should I leave define content types and have these persisted to the Orchard database or should these just be defined in the orchard dB and be persisted to the application database. This is key.

It would seem the recognised way of performing the integration of a standard MVC application is to add this as a module to orchard, add a modules.txt and away you go. Unfortunately, this leaves absolutely zero ability to change or manipulate the layout of the application (due to the construction of the content as a single lump which constituents the application).

An alternative (which I touched on in a previous paragraph) would be to define your application Lego bricks (thus allowing you to modify the layout using orchard tooling) which by composition make up your complex web application but this would mean all application data going to the Orchard db.

I am not sure the Orchard community has a decent answer for this common scenario, it would be useful for this to be included in some best practice with a suitable design pattern.
Aug 6, 2013 at 7:37 PM
I don't understand what you mean by this: "Unfortunately, this leaves absolutely zero ability to change or manipulate the layout of the application (due to the construction of the content as a single lump which constituents the application)"
Aug 7, 2013 at 12:12 PM
All the content is in a single module and represented by a single content type. Therefore, this content can be positioned in one of the zones.

If the content is cut up into pieces (with different content types) I can put these where I wish. Does this make sense? Would it be more useful to provide some code as an example?

As an aside, I believe this is the 'elephant in the room' for Orchard (it was a unanswered question at the harvest event) which would really benefit the community if clear guidance were available.
Aug 7, 2013 at 1:09 PM
Edited Aug 7, 2013 at 1:12 PM
What you described is exactly how Orchard works. Each content type is built from different content parts ("Lego bricks" as you described earlier) by design. Each part:
  • contains some data and logic that describe some added functionality and
  • may or may not be represented visually by any number of templates (one is most common) that can be put wherever you want on a page
So there is no "elephant in the room" - content types and parts have always been Orchard base concepts.

You're not forced to use Orchard content type system, though. On one end there are custom (I'd rather use this word instead of "complex") applications that are just plain old ASP.NET MVC apps wrapped inside a module, using very little Orchard built-in functionality. On the other - applications fully utilizing Orchard architecture (content types, parts, dependency injection, available services, users, permissions etc.). There is no silver bullet - the best solution lies somewhere in the middle and depends on a particular scenario.
Aug 7, 2013 at 3:06 PM
To give you an idea what is possible:

Contains more than meets the eye (license service module, downloadable 'request' service module, a module acting as an endpoint for our new 'always on' system that is designed to handle 20k+ concurrent connections, custom API that our software uses to handle user sync (from / to our software) + uploading our users their 'scores', custom feeds module). It also 'runs' a 2nd site inside not as a tennant + in the near future it'll also contain full integration with our client' shop, ...)

Only thing that I will repeat, at least for V1.6 because we're using that: Do not expect to be able to use ALL the Orchard features if you plan to have plenty of 'content' (users count as content too) since the 'lego brick' system can't handle this that well (and some modules (used to?) blow up with too much content, like the taxonomy module)

In general, it was plenty of work for us (me and another colleague), but I still think Orchard was the best choice (even with its quirks). Just expect to do a lot of custom work. Sounds bad, but almost all our modules we could base on existing modules on the gallery.
Aug 7, 2013 at 3:52 PM
Thank you for this response.

I agree as I described above that orchard has the 'Lego brick' concept at its heart but if you integrate your complex application (as described here ) you will not be able to redefine the layout of your site unless you cut up the standard MVC application into its content parts. With a single module you might as well miss orchard out altogether? What might make you reconsider is the use of some standard orchard functionality which may be more challenging to use because your application is within a single module (this is arguable based on orchard experience)
Aug 7, 2013 at 4:01 PM
Edited Aug 7, 2013 at 4:07 PM
I have taken a look at the site which looks very neat. I can imagine the content types that are used to build up this page. With the investment you have made I would also imagine that you can change very quickly (without code change) the look and feel of this, which is one of the reasons you choose orchard in the first place. If you had coded this in a single module, you would have been able to use orchard but could not have achieved the layout change without a code change.

Before anyone says, this should be covered in the requirements :-)!
Aug 7, 2013 at 4:23 PM
Seems you have more a problem of software architecture then tool selection
Aug 7, 2013 at 4:34 PM
Edited Aug 7, 2013 at 4:37 PM
As this thread is an orchard specific question I can only agree with your comment. But I believe this is more about the position this product occupies in relation to being used on more varied applications. (As detailed above). Unless this product can be proven in these more complex applications it will be reduced to more peripheral and hobbyist web sites which would be an enormous pity!
Aug 7, 2013 at 9:48 PM
It has been proven to work. We've all tried to explain that none of the scenarios you described are impossible, and have probably already been done, but it's beginning to look as if you are only trying to confirm a pre-established conclusion. There is a spectrum of integration you can achieve, it all depends on your specific scenario (which we still don't know much about after all these messages). For example, a classical MVC design can still take advantage of the theming infrastructure and create and send shape wherever it wants, or handle non-themed views if that's more appropriate. It can also take advantage of any number of Orchard services as relevant, using simple dependency injection. I'm really struggling to understand what exactly you're asking, sorry.