Article View/Read Count

[csharpfritz]

Article View/Read Count

[csharpfritz]

This is a cool idea, and I think will drive a new Model in the project: ArticleAnalyticDetails

Perhaps this object has a references back to the article and the number of views each day.

What is the difference between a read and a view? Is a Read when a visitor reaches the bottom of the page?

[summer600]

Is it really necessary to create this new entity now. It seems this only required a simple field "Views" of type int to count the number of views of the article. That can easily be incorporated in the Article entity itself.
Of course if, in the furute the number of analytics details we would like to keep track of grows it might be better to seperate these into a new related entity as you suggest @csharpfritz but for now I think that is too much.

What is your reasoning to start with a seperate entity from the start?

[csharpfritz]

@summer600 - you're right... I wasn't thinking of YAGNI when I wrote that response.

My thinking in using a separate entity is that we wouldn't want to update the Article record every time someone navigates to that page. The read-caching on an Article page is what we want to drive for later performance concerns.

[summer600]

@csharpfritz But even if you use a seperate entity on each Read that entity will have to be updated so there are database updated anyway. When you update only 1 field the EF SaveChanges() will produce an update statement that only updates (sends over the wire back to the database) this one field. You could consider that even more optimal since the Article record will have to be read anyway, but using a seperate entity will require reading that additional entity on a seperate sql round-trip wouldn't it?

And when you consider scaling it up you might switch to pushing read counter updates to a servicebus that is processed in the background, updating the read counter async of the actual Article views.
Then it does not matter either whether it's in Article or not. Wiki's, but Blog posts especially, usually display or use the read counter in a View anyway so putting it in Article will make it more easily available.

If you mean you want to go to a scenario that caches the Article in memory or some sort of external Cache (redis) then wouldn't it still make no difference? You would still want to have access to the read counter for display purposes. So you would cache thos other entity as well, of call some sort of api endpoint that does a counter++ and then again it would not really make a difference because ultimately the database hase to be updated? For other analytics counters like "Application insights" data you are correct but I think the Read counter will be used in the views and is used more like application data than analytics data.

I find it hard to seperate those types of counter, like Blog posts with twitter/facebook/... social buttons with counts below the Blog post or Application insights data. But these usually come from another platform anyway and are not stored locally at all.

I still feel like including the Read counter in the Article Entity will provide no performance or scaling advantage in this particular case and since we are building this out from very small I would keep it simpler to begin with.