I m new to Umbraco, I have watched Umbraco.tv videos and want to use Umbraco in a project as a cms for managing and editing content. I am highly thankful for your guidance, time and for your thoughts on 3 questions:
How a Umbraco based data driven proejct should be architecutured ? For custom database tables do you use a separate database or same Umbraco database ?
How you work with custom data (non content) ? Do you make everything a document type, even if it is data which you are not going to create content of, for example a simple form submitted data ?
For DAL what technology or ORM you use ? Does Umbraco provide any API for saving simple data which is not a content or document type ?
Thank you so much once again.
1 The architecture question is important but it also has be considered against how complex the project needs to be.
I would usually recommend a separate database for non-Umbraco data since this keeps everything nicely independent and manageable especially as projects grow. It also means that CMS-specific data (i.e. content) can be kept separately from none-CMS data, e.g. user registrations.
However, if the project is small and isn't likely to grow, keep it simple. Use the same database and piggy back off Umbraco's implementation of the Petapoco ORM. For example:
ApplicationContext.DatabaseContext.Database.Save(new Thing());
Or
var item = ApplicationContext.DatabaseContext.Database.Single(thingId);
2 For custom data, again it's a matter of need, maintainability and simplicity. Only use document types for what needs to be and can be stored in the CMS. My personal rule is that if it isn't content or organises content then it doesn't belong in the CMS. For example news and news categories obviously belong in the CMS. However, the comments made on an article have no reason to in the CMS.
3 With regards to DAL, as I have said, Umbraco has an implementation of Petapoco that can be used out of the box. If the project is basic enough, just use that. There is little point in using anything else unless you need some separation and/or some additional grunt in which case I would recommend using NHibernate or EF.
In addition to the points above,