this is more a theoretical discussion but having just started Umbraco, i could do with some advise when it comes to external data and how best it can be used in templates etc.
so for this discussion, i'm making a site that is going to contain recipes, over time this could grow to 1000's, and within them are things like ingredients that should also be normalized.
now i'm guessing the best way to store the information for these is in an external database as opposed to making things like Ingredient custom data data types within umbraco?
but then what is the best way to make these recipes editable and available through umbraco? is it to create a backend extension where a user can load/edit and save the data, then use a surface controller to get the data?
or can i manage this all through the document types and templates? would that be performant? i guess the same sort of theory also applies to an eCommerce site, would you create a single document for each product or would you just make a surface controller and singular view for them with query string parameters? or would that depend of if the content people wanted direct control of a particular product page?
i know this is a bit of a broad subject and there are many ways to skin a cat so to speak, but im just interested in the views of people who have experience in handling content both within and outside of umbraco, pro's cons etc
If i was going to done something similar to this, i would gather that data in its down database. I would then create an API that i could call to manage/query that data. In essence, i would separate it from the CMS completely.
I would then create some hijacked pages/templates that would take the recipe name/id and obtain it from the API service and return it to the view.
As for editing the data, this could be achieve by a custom section in the back office. Again, as all the data and functions are controlled by an API, you would just need to create the interfaces to meet your requirements.
Extra care would need to be take in how to filter the data down, if you are going to get a LOT of records.
An added benefit of making it an API service is reuse of the data in another manner later on (maybe a mobile app or something).
very interesting response and kind of along the same things i was thinking but its good to know that other people ave similar thoughts, just to clarify, when creating an API would you extend the Umbraco API controllers (UmbracoApiController) for front end and what ever the backend ones are to do this?
I would create a complete stand alone API app and expose everything through that.
Then i would use the Umbraco API facility to talk to it for the front end for sure.
While this may cause more work initially, i think it will make maintenance a lot easier in the future.
Umbraco Strategies with external data / Best Practices
Hello,
this is more a theoretical discussion but having just started Umbraco, i could do with some advise when it comes to external data and how best it can be used in templates etc.
so for this discussion, i'm making a site that is going to contain recipes, over time this could grow to 1000's, and within them are things like ingredients that should also be normalized.
now i'm guessing the best way to store the information for these is in an external database as opposed to making things like Ingredient custom data data types within umbraco?
but then what is the best way to make these recipes editable and available through umbraco? is it to create a backend extension where a user can load/edit and save the data, then use a surface controller to get the data? or can i manage this all through the document types and templates? would that be performant? i guess the same sort of theory also applies to an eCommerce site, would you create a single document for each product or would you just make a surface controller and singular view for them with query string parameters? or would that depend of if the content people wanted direct control of a particular product page?
i know this is a bit of a broad subject and there are many ways to skin a cat so to speak, but im just interested in the views of people who have experience in handling content both within and outside of umbraco, pro's cons etc
thanks
If i was going to done something similar to this, i would gather that data in its down database. I would then create an API that i could call to manage/query that data. In essence, i would separate it from the CMS completely.
I would then create some hijacked pages/templates that would take the recipe name/id and obtain it from the API service and return it to the view.
As for editing the data, this could be achieve by a custom section in the back office. Again, as all the data and functions are controlled by an API, you would just need to create the interfaces to meet your requirements.
Extra care would need to be take in how to filter the data down, if you are going to get a LOT of records.
An added benefit of making it an API service is reuse of the data in another manner later on (maybe a mobile app or something).
very interesting response and kind of along the same things i was thinking but its good to know that other people ave similar thoughts, just to clarify, when creating an API would you extend the Umbraco API controllers (UmbracoApiController) for front end and what ever the backend ones are to do this?
I would create a complete stand alone API app and expose everything through that. Then i would use the Umbraco API facility to talk to it for the front end for sure.
While this may cause more work initially, i think it will make maintenance a lot easier in the future.
Agree with Richard that a complete stand-alone API app is a good idea.
is working on a reply...