Is Orchard good for Database Applications

Topics: Administration, General
Jan 6, 2014 at 7:05 PM

We have couple of Intranet/Internet web applications in our company. Almost all of our web applications are Data driven applications. Mostly Data Entry Forms, Data Validation, Workflows, Reports etc.

We were looking forward to build a solution, which will be common place holder for all our disconnected Web applications.

I am believing that Orchard is mostly for Content Sites rather than Data applications. Is anybody using Orchard for Data Applications which are mostly data centric (Data Entry Forms, Data Validations, Data Imports, Data Exports, Analytics, Reports..etc).

Is Orchard suggested for web sites which are mostly data driven (Not Content Publishing).

Jan 6, 2014 at 7:55 PM
I think probably Orchard is not the best option here.

Apart from being a CMS (and having features like user, content, media management) it's a powerful web framework (with a very flexible plugin architecture, thousand ways to customize and extend). However it's not a tool for quickly building data entry/report applications: you can do anything in Orchard that you can do from a web app but with Orchard you have to almost start from scratch: you'll spend most of your time building the forms (even when not directly coding the <form></form> part, but still developing pieces of forms) and there's no reporting built-in so you have to write it yourself. Orchard has its own notions of handling workflows (and also a module called Workflows) so it'd depend on your concrete use-cases how and what you can leverage.

So if you want infinite customizability and extensibility from a generic web application framework, use Orchard. If you want to be able to quickly add reports, various generated lists and forms then there are probably better tools for the task.
Jan 16, 2014 at 12:33 PM
We are planning on using Orchard CMS as a framework for us to develop business applications. Currently designing a CRM which will be developed as an Orchard Module.

Intention is to make it as modular as possible. Once deployed it has to create all its database tables(can be done with migrations), disable all unused modules(also can be done through migrations or recipe), change the admin theme entirely and show only the CRM navigation items (can be done through OrchardSupressDependency).

A couple of things i needed help on :-
  • Admin v/s Frontend - I cant think of a good enough reason to develop the application on the frontend rather than the admin side. The only thing that comes to mind is that clients can develop custom themes and rearrange the content if everything is made as widgets - Im not at all convinced about this approach.
  • Content Item v/s Record - I understand Content Item comes with a lot of cool features out of the box - things like Version, Logging, Custom Fields(EAV), Soft Delete, Workflow. It would really be nice to make use of these features, but if we use non content items / records then it keeps the code pure MVC and lesser dependent on Orchard (considering one day orchard guys might change the way content items work).
  • 1.7.x vs 1.8 - Is the .net4.5 nightly build stable enough to be used? Would be nice to develop on MVC5 and WebAPI2.
Finally can anyone point me at an opensource solution that does something similar?

I am looking for someone gone down the same route of using Orchard as a framework to share their experience and lessons learnt while developing. Most importantly about content item vs record.


Jan 16, 2014 at 2:43 PM
If you only want to give users your custom application then it can be just on the frontend. If you want to build your application on top of Orchard and you want to give users an Orchard app with CRM then you'll need the backend too.

I don't see why you wouldn't want to use content items when you're already using Orchard: the content model is basically the point of Orchard :-). (Well, you could use Orchard strictly as a framework too...) With 1.8 (current 1.x) you wouldn't need records for your parts, as everything is now stored in infoset (too) so it's very well scalable.

1.7.x is stable and generally pretty safe to use (only code gets pushed there that can possibly be released as a next revision to 1.7 any time). If you just start then 1.x is fairly safe to use too: migration from 1.7 is not yet completely done but on its own that version works well too. Also if you start developing now there's a good chance you'll see a 1.8 release before you finish anyway.

BTW I think you might be interested in something that I'm working on, please contact me (either through Codeplex or through Lombiq: