Hello all,
I am currently rebuilding the uHangout website where I have the YouTube videos imported in as Umbraco content nodes.
I am building a WebAPI to query & fetch these videos. i.e most popular videos based on a property such as viewCount on each node for a video.
I am using the ContentService to query my nodes which returns a single or a list/IEnumerable of IContent and when returning that in a WebAPI there is a lot of bloat of extra properties and info in the JSON payload that I do not need.
To make the payload leaner and not so bloated I thought about creating a clean POCO so I only return what I need in my JSON payload from the properties on the Video Node that I am storing.
I want to make my life easy and not have to worry about writing model builder/hydration code of getting the properties from the IContent and populating my POCO and thought it's best to use a tool to help me do this leg work for me.
I asked on twitter today what should I use next Ditto or Stephan's Model Builder (Zpqrtbnk) and obviously I got some very biased/opinionated answers.
However I want to open this up and have a wider discussion of the pros and cons of each system, so let's open the floor up and discuss!
Wouldnt it be better performance to use umbraco helper instead of content service? From my understanding the content service makes a database query whereas umbraco helper queries the cache and is quicker.
Can't help with the model builder question. I am new to Umbraco and haven't used it yet, not too sure of what the benefit is. I am just initializing my custom models in controller as I usually want to add some logic or alter some data. Would it be prudent for me to learn how to use a model mapper?
To quickly answer your question about mapping IContent ... Unfortunately I don't think either Ditto or ModelBuilder can help you - as they ultimately deal with IPublishedContent (as others have mentioned).
I'll get around to a longer answer about pros/cons of both approaches very soon.
No, Umbraco Mapper - doing a similar job to Ditto as I understand - also works on IPublishedContent. To be honest though in this example I'd possibly not look to use one of these tools at all. One of the benefits of them is they give you much cleaner view models to work with in your views - clearer for front-end developers less familiar with the Umbraco APIs to use, Intellisense in VS.Net etc. Given it'll be the consumer of your API that's going to be doing that, and presumably working with the JSON, you wouldn't get that part of benefit.
So whilst you will have to do a little bit of left-right mapping, for this example you might just use LINQ and project to either a POCO or an anonymous object, and return that as JSON.
If you do want something to do convention based mapping, you could maybe look at Automapper? Not tried that with IContent, but for more generic object to object mapping that might work for you.
Ismail neither approaches are TRUE code first and not designed to build my DocTypes magically by writing a ton of C# POCOs and for it them magically appear in Umbraco, but the other way round to Map the document types I have setup using the Umbraco backoffice and map them to POCOs so I have cleaner Views and or C# for say WebAPI controllers as well.
So they are two totally different things and can get confused a bit & Ditto, along with Model Builder often get tar'd with the brush as the 'Code First' approaches.
@Lee & @Andy I have never used AutoMapper and will look into it.
I may need to use the same logic of getting the XX most recent videos and XX most popular videos etc in both a WebAPI controller along with Views so initial page load has these items rendered in the DOM and subsequent calls are done to the WebAPI.
Is AutoMapper still going to be the best option for me guys?
Wrote a reply earlier but lost it - doh ! but to summerise:
If you want your models to 'do stuff' then I'd go with the Model Builder and the default factory, as it's the responsibilty of the model's properties (and maybe custom methods) to return (and potentially manipulate) the Umbraco data - becuase these models inherit from PublishedContentModel, there are probably properties you don't wish to serialize - as Andy said, you could use LINQ and project to something lighter to return (or possibly inherit form a common class that marks with attributes the properties of PublishedContentModel that you don't want to serialize)
Ditto and UmbracoMapper take a different approach and map Umbraco data to properties of another object, (I've not used UmbracoMapper) but DItto will map to a 'clean' POCO that doesn't have to inherit from PublishedContentModel. This has some advantages as you mentioned above - lighter and easy to serialize - but there's another advantage of using 'clean' POCOs, in that they can be used before their corresponding data in Umbraco exists - for example, such a POCO could be supplied to a service which creates the Umbraco content.
@Lee is there a reason why Ditto shouldn't do IContent <--> Model mapping in the future ?
@Hendy - the only reason is that "I" haven't had a need to map IContent yet. If someone wants to do that, cool - but I don't have that "itch" myself. :-)
What did you settle on in the end? I ask because I have a similar need (for consumption in a PhoneGap/Cordova app), and also trying to weigh up pros and cons...
Ditto or Stephan Model Builder...?
Hello all,
I am currently rebuilding the uHangout website where I have the YouTube videos imported in as Umbraco content nodes.
I am building a WebAPI to query & fetch these videos. i.e most popular videos based on a property such as viewCount on each node for a video.
I am using the ContentService to query my nodes which returns a single or a list/IEnumerable of IContent and when returning that in a WebAPI there is a lot of bloat of extra properties and info in the JSON payload that I do not need.
To make the payload leaner and not so bloated I thought about creating a clean POCO so I only return what I need in my JSON payload from the properties on the Video Node that I am storing.
I want to make my life easy and not have to worry about writing model builder/hydration code of getting the properties from the IContent and populating my POCO and thought it's best to use a tool to help me do this leg work for me.
I asked on twitter today what should I use next Ditto or Stephan's Model Builder (Zpqrtbnk) and obviously I got some very biased/opinionated answers.
However I want to open this up and have a wider discussion of the pros and cons of each system, so let's open the floor up and discuss!
Cheers,
Warren
Wouldnt it be better performance to use umbraco helper instead of content service? From my understanding the content service makes a database query whereas umbraco helper queries the cache and is quicker.
Can't help with the model builder question. I am new to Umbraco and haven't used it yet, not too sure of what the benefit is. I am just initializing my custom models in controller as I usually want to add some logic or alter some data. Would it be prudent for me to learn how to use a model mapper?
Hi Warren,
ZpqrtBnk Umbraco Models Builder can generate a complete set of strongly-typed published content models for Umbraco to be used in the MVC views.
Ditto is a lightweight POCO mapper for Umbraco 7, you need to create models before mapping.
So if you want to do less and light models for json, ZpqrtBnk is better.
Thanks, Oleksandr
To quickly answer your question about mapping
IContent... Unfortunately I don't think either Ditto or ModelBuilder can help you - as they ultimately deal withIPublishedContent(as others have mentioned).I'll get around to a longer answer about pros/cons of both approaches very soon.
Cheers,
- Lee
No, Umbraco Mapper - doing a similar job to Ditto as I understand - also works on IPublishedContent. To be honest though in this example I'd possibly not look to use one of these tools at all. One of the benefits of them is they give you much cleaner view models to work with in your views - clearer for front-end developers less familiar with the Umbraco APIs to use, Intellisense in VS.Net etc. Given it'll be the consumer of your API that's going to be doing that, and presumably working with the JSON, you wouldn't get that part of benefit.
So whilst you will have to do a little bit of left-right mapping, for this example you might just use LINQ and project to either a POCO or an anonymous object, and return that as JSON.
If you do want something to do convention based mapping, you could maybe look at Automapper? Not tried that with IContent, but for more generic object to object mapping that might work for you.
Andy
If you missed this then https://www.youtube.com/watch?v=Hr1irQ0h5J8 (Umbraco UK festival 2014 - Pete Duncanson - Why Code First Is Bad)
@Warren - Good point by Andy, AutoMapper is what you want for your problem.
Ismail neither approaches are TRUE code first and not designed to build my DocTypes magically by writing a ton of C# POCOs and for it them magically appear in Umbraco, but the other way round to Map the document types I have setup using the Umbraco backoffice and map them to POCOs so I have cleaner Views and or C# for say WebAPI controllers as well.
So they are two totally different things and can get confused a bit & Ditto, along with Model Builder often get tar'd with the brush as the 'Code First' approaches.
@Lee & @Andy I have never used AutoMapper and will look into it.
I may need to use the same logic of getting the XX most recent videos and XX most popular videos etc in both a WebAPI controller along with Views so initial page load has these items rendered in the DOM and subsequent calls are done to the WebAPI.
Is AutoMapper still going to be the best option for me guys?
Hi Warren,
Wrote a reply earlier but lost it - doh ! but to summerise:
If you want your models to 'do stuff' then I'd go with the Model Builder and the default factory, as it's the responsibilty of the model's properties (and maybe custom methods) to return (and potentially manipulate) the Umbraco data - becuase these models inherit from PublishedContentModel, there are probably properties you don't wish to serialize - as Andy said, you could use LINQ and project to something lighter to return (or possibly inherit form a common class that marks with attributes the properties of PublishedContentModel that you don't want to serialize)
Ditto and UmbracoMapper take a different approach and map Umbraco data to properties of another object, (I've not used UmbracoMapper) but DItto will map to a 'clean' POCO that doesn't have to inherit from PublishedContentModel. This has some advantages as you mentioned above - lighter and easy to serialize - but there's another advantage of using 'clean' POCOs, in that they can be used before their corresponding data in Umbraco exists - for example, such a POCO could be supplied to a service which creates the Umbraco content.
@Lee is there a reason why Ditto shouldn't do IContent <--> Model mapping in the future ?
Thanks,
Hendy
@Hendy - the only reason is that "I" haven't had a need to map
IContentyet. If someone wants to do that, cool - but I don't have that "itch" myself. :-)Warren,
What did you settle on in the end? I ask because I have a similar need (for consumption in a PhoneGap/Cordova app), and also trying to weigh up pros and cons...
Phil
Hi Phil,
We are using Zbu.Model.Builder, and very happy now, it's really saving of time in development views.
Thanks
is working on a reply...