Comments (8)
I'm also interested in this. We still map manually because of performance and flexibility. I looked at Ditto and was thinking about using it, but open to other ways.
from modelsbuilder.original.
Imagine you have a Google Maps property type with an associated property value converter, that would return Location
objects, each object having a Latitude
(float), Longitude
(float) and Zoom
(int) properties. Internally, the property type stores a JSON string in the database, eg {lat:47.222,lng:3.5598,zoom:3}
.
When you get content.Location
from a model, it returns a Location
object, and you can write things such as @Model.Location.Latitude
. Internally, all the model does (at least those models built with the models builder) is define a property as:
public Location Location
{
get { return this.GetPropertyValue<Location>("location"); }
}
So really, whether you use a model or not should not make a difference, perfs-wise: it all comes down to the performance of GetPropertyValue<TValue>(string alias)
. Let's see what that method does:
- get the property itself ie
content.GetProperty(alias)
- get the property value ie
property.GetValue()
In (1), GetProperty
does:
return Properties.FirstOrDefault(x => x.PropertyTypeAlias.InvariantEquals(alias));
That could be optimized by using a dictionary of some sort, and it definitively has a cost, but probably a marginal cost related to all the things that take place when rendering a page.
In (2), the value is obtained from the raw database value, via conversions specified by the property value converter. There are plenty of Lazy<T>
in there that ensure that the conversion runs only one, for that property instance.
So, assuming you write, in a view:
<div>@Model.Location.Latitude</div>
<div>@Model.Location.Latitude</div>
<div>@Model.Location.Latitude</div>
Then on the first row, (1) runs and then the conversion runs. On the next rows, only (1) runs (so you take the lookup perfs hit) but the conversion does not run again.
Finaly, because published content objects are not (for the time being) cached outside the current request, this is what will happen on every request, ie we do not share the conversion result between requests (that's a thing that the "new cache" should fix).
And now... back to your questions...
No, the converters would not run each time but only once per request. But anyway I would advise against caching IPublishedContent
instances outside of the current request for the time being, as the cache is not designed to support that and "anything" could happen.
Yes, a private field in the model would somehow bring a perfs gain, although that field would need to be lazy in a way so that the conversion runs only if you actually need the property value - my personal feeling is that the gain would be marginal but I can be wrong.
And so, my (personal, again) opinion at the moment is that adding private fields on top of what we already have would be premature optimization - but I'm happy to discuss it!
from modelsbuilder.original.
Thank you for your comprehensive response
Just to make sure, the implementation I'm thinking about looks like this:
public Location Location
{
get
{
if (_location == null)
_location = this.GetPropertyValue<Location>("location");
return _location;
}
}
Location _location;
I might try the current implementation and this implementation and do some performance testing to find out for sure, if that's ok with you?
from modelsbuilder.original.
What if GetPropertyValue<Location>
can return null
? ;-) You'd need a Lazy of some sort in that case. Just being picky here: sure, go ahead, I'm quite interested in the perfs testing results! There is going to be a gain, for sure, but is it going to be significant?
from modelsbuilder.original.
Ah yes, ofcourse, lol!
But if there's a performance gain for sure, there's no reason to not implement it right? ;-)
Would it be hard/time consuming? Looks like a small template adjustment to me, but I haven't build this ;-)
from modelsbuilder.original.
Like, implement it in the builder? Should not take that long. And then it's balancing the cost of creating Lazy instances vs. doing the lookup each time. Could even make it an option anyways. Mmm... will look into it (changing the issue from question to enhancement).
from modelsbuilder.original.
:-D Looking forward to start using this project, looks really promising!
from modelsbuilder.original.
As I'm working on the NuCache I realize that this is not going to make it. See, the NuCache caches the contents once and for as long as it is not modified. But, a property value may reference another content and therefore you need to let the Core manage the cache refreshing. If you cache in the model, you may optimize, but you're going to create inconsistencies.
from modelsbuilder.original.
Related Issues (20)
- Generating models using the VS extension can cause namespace issues HOT 3
- Cleaner csproj include generated files HOT 1
- Can't Rebuild Models After Deleting Document Type HOT 6
- Interface definition only generated when document type is in use HOT 1
- Request error: The URL returned a 404 (not found): /App_Plugins/ModelsBuilder/modelsbuilder.html HOT 1
- Provide option for generated code to use Language Fallback HOT 7
- ModelsBuilder API Generates first IPublishedElement then never finishes HOT 10
- VS Extension: Method not found: 'System.String Umbraco.ModelsBuilder.Building.Compiler.CreateValidIdentifier(System.String)' HOT 2
- v4: Repository shouldnt link to local nuget server
- v4: If Document type with Template is created Umbraco fails with save of Document Type
- Implemented property keeps being generated HOT 6
- ModelsBuilder on Umbraco v8.8 HOT 10
- v4: Generator should be swappable / extendable
- Generated Models missing PublishedElementModel on generated model.
- Stack Overflow when implementing same interface in generated and partial class
- VS Extension install issue
- Execute ModelsBuilder Programmatically
- When generating models for IPublishedElement it adds a controller no matter what
- UmbracoModelsBuilder: UmbracoModelsBuilder failed to generate code: NullReferenceException HOT 1
- VS2022 HOT 5
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from modelsbuilder.original.