I'm new to Umbraco and have a potentially large data driven website that also needs to be content driven and was wondering how to approach integrating it into Umbraco.
Do I have to put data access code in the code-behind of user controls within the Umbraco project or can I create a business layer class libraries or use an ORM? How do you create a DAL and use it through Umbraco's user control structure?
I was wondering how you to structure the projects using Visual Studio? Do you start by creating a new ASP.NET project or class library and then copy these into the Umbraco solution?
I know these are very broad questions but I'm not sure where to start. Any help or exampled would be appreciated.
It really depends on how you plan on managing the data within your application.
From personal experience, I would keep the data to be managed as Umbraco data - so creating document types and content nodes that, in essence, is my "table" structure. Then, I'd put the entire Umbraco site into a Visual Studio solution, create a separate web application project for the custom logic, POCO classes to wrap the Umbraco API, and then set it up as a dependency, with MSBuild targets to copy usercontrols across in the AfterBuild target. I can subsequently run my project using F5 and Cassini, or (my personal preference) set it up as a site within my local IIS and attach to process with F5.
I am currently working on the Blog4Umbraco project, which has a single C# project which contains all the classes and logic for the package. It contains POCO logic in one folder and usercontrols in another, all utilising the Umbraco API. It also has an EF model for a custom table structure. It might be useful for you to look over and review it, along with other packages that other people have built, to see how different people write extensions and addons to Umbraco.
I have a much more complex Umbraco project, with 20 projects inside a Visual Studio solution, and I'd be happy to do a 15-minute walkthrough of it sometime, if you need some more advanced hints & tips - hit me up via Twitter (@benjaminhowarth).
Thanks for the quick reply. It's really helpful. I'm starting from scratch on this so excuse the dumb questions as I evaluate Umbraco.
If I use Umbraco data for data storage can this be modelled and accessed directly using Linq2SQL/ EF4 as in a regular application? I'm just curious as to how easy it is to build up all the 'tables' and data access using the Umbraco document types. I'm sure there's a good reason for keeping it all together.
The thing is, my app will have a lot of back-end admin forms that will not need to be content managed. This would be best suited to a traditional webforms/MVC app and a straighforward data model. I'm not sure how the 'front-end' CMS pages and the back-end admin pages should be developed and how the data layer is implemented.
I think I need to get the project structure set up as you suggested and play with it first. It looks like once you commit yourself to Umbraco there's no going back!
Hi - I agree with Benjamin on using the Document types to map out your datastructure.
At the most basic level document types are just pages, but you will soon find that you can use them to map entire business objects and use the CMS to manage large collectiosn of these.
In settings, right click on document types and try the "Export to .NET". This allows you to do Linq to Umbraco (http://www.farmcode.org/post/2009/02/24/Linq-to-Umbraco.aspx) - which I personally find to be the cleanest and most structured way of workign with Umbraco (I very much dislike the late bound nature and overly complex syntax of XSLT).
If you use Linq 2 Umbraco it's a good idea to add some caching, and then use publish event handlers to clear relevant data.
So my answer to your general question would be:
1. A repository that contains the generated Linq 2 Umbraco datacontext and any data retrival methods you need. 2. A "service" or "business logic" project, that handles caching and formatting/shaping data, paging etc. 3. A web application that references the abastractions created along with the POCOs, and the service layer.
Data-driven website architecture with Umbraco
Hi,
I'm new to Umbraco and have a potentially large data driven website that also needs to be content driven and was wondering how to approach integrating it into Umbraco.Do I have to put data access code in the code-behind of user controls within the Umbraco project or can I create a business layer class libraries or use an ORM? How do you create a DAL and use it through Umbraco's user control structure?
I was wondering how you to structure the projects using Visual Studio? Do you start by creating a new ASP.NET project or class library and then copy these into the Umbraco solution?
I know these are very broad questions but I'm not sure where to start. Any help or exampled would be appreciated.
Hi Brendan,
It really depends on how you plan on managing the data within your application.
From personal experience, I would keep the data to be managed as Umbraco data - so creating document types and content nodes that, in essence, is my "table" structure. Then, I'd put the entire Umbraco site into a Visual Studio solution, create a separate web application project for the custom logic, POCO classes to wrap the Umbraco API, and then set it up as a dependency, with MSBuild targets to copy usercontrols across in the AfterBuild target. I can subsequently run my project using F5 and Cassini, or (my personal preference) set it up as a site within my local IIS and attach to process with F5.
I am currently working on the Blog4Umbraco project, which has a single C# project which contains all the classes and logic for the package.
It contains POCO logic in one folder and usercontrols in another, all utilising the Umbraco API. It also has an EF model for a custom table structure. It might be useful for you to look over and review it, along with other packages that other people have built, to see how different people write extensions and addons to Umbraco.
I have a much more complex Umbraco project, with 20 projects inside a Visual Studio solution, and I'd be happy to do a 15-minute walkthrough of it sometime, if you need some more advanced hints & tips - hit me up via Twitter (@benjaminhowarth).
HTH,
Benjamin
Hi Benjamin,
Thanks for the quick reply. It's really helpful. I'm starting from scratch on this so excuse the dumb questions as I evaluate Umbraco.
If I use Umbraco data for data storage can this be modelled and accessed directly using Linq2SQL/ EF4 as in a regular application? I'm just curious as to how easy it is to build up all the 'tables' and data access using the Umbraco document types. I'm sure there's a good reason for keeping it all together.
The thing is, my app will have a lot of back-end admin forms that will not need to be content managed. This would be best suited to a traditional webforms/MVC app and a straighforward data model. I'm not sure how the 'front-end' CMS pages and the back-end admin pages should be developed and how the data layer is implemented.
I think I need to get the project structure set up as you suggested and play with it first. It looks like once you commit yourself to Umbraco there's no going back!
Thanks,
Brendan
Hi - I agree with Benjamin on using the Document types to map out your datastructure.
At the most basic level document types are just pages, but you will soon find that you can use them to map entire business objects and use the CMS to manage large collectiosn of these.
In settings, right click on document types and try the "Export to .NET". This allows you to do Linq to Umbraco (http://www.farmcode.org/post/2009/02/24/Linq-to-Umbraco.aspx) - which I personally find to be the cleanest and most structured way of workign with Umbraco (I very much dislike the late bound nature and overly complex syntax of XSLT).
If you use Linq 2 Umbraco it's a good idea to add some caching, and then use publish event handlers to clear relevant data.
So my answer to your general question would be:
1. A repository that contains the generated Linq 2 Umbraco datacontext and any data retrival methods you need.
2. A "service" or "business logic" project, that handles caching and formatting/shaping data, paging etc.
3. A web application that references the abastractions created along with the POCOs, and the service layer.
is working on a reply...