Should Orchard CMS content types be used for the application domain model?

I am writing an application using ASP.Net MVC4 where most of the data was stored in MongoDB. This has worked great for most of what I would call the "meat" of my application, the functionality he made to do it sets it apart.

However, now I need to add static content and administrative capabilities (setting up accounts, billing, help, etc.). I am very inclined to use Orchard CMS to handle all of these functionality and then migrate what I have done so far to Orchard modules.

The question is, how much of my data should I use to use Orchard content models? I plan to continue to store at least some of my data in Mongo, so now I'm not sure where to put the dividing line between what's going on.

Have you already used the web app in Orchard? Where did your domain data go? If you've used content types, have there been any tutorials?

+3


source to share


1 answer


Why do you want to use MongoDB? In Orchard, all data access is done by NHibernate using the xxxRecord classes where a virtual property is mapped to a column. It works with SQL Compact, SQL Server 2008 (and R2) and SQL Azure.

I don't know the status of RavenDB, but there could be a module using RavenDB to store BLOB data or just use it as a data store without sql.

Personally, I would not use multiple data stores.



The ContentType contains multiple "dockable" ContentParts and ContentFields, either in code or using the orchard admin user interface. U can use the repository if you want, but only for data that is not directly ContentPart. The DefaultContentManager has versioning, publishing, deleting, etc. If u removes the ContentType, it just gets the flag that was removed. (unless you are using any other module that does delete statements). There is a risk using a repository if you think the item still exists while it does not.

As a definitive answer to your question: Yes, you should use ContentType as your domain model and you don't need to worry about making a different request.

+1


source







All Articles