Re: cache key problem

That was a problem in my code, not in the original article. Whoops.

Nope, definitely not huge sins given the scope of this app. But it does violate SoC. It’s a choice whether or not you want to adhere to that principle.

Testability, however, is always a concern. That governs the long-term maintainability of the system. If this app didn’t have any business logic, why even build a three-tier application?

In that case, having your “Business Logic Layer” be, essentially, view formatted and accessible data, is pretty much the norm.

I’m not fond of the HttpContext.Current call, or the direct management of Cache – but neither are huge sins.

I’m planning on a follow-up post. I’m contemplating on a screencast, as the decisions on direction are more important than the final destination.

oh wait, that’s just the snippet of code from a microsoft magazine…whoops!

The worst part of the whole deal is someone (probably in the thousands), will read that article and assume that since it is from a MS mag, it must be considered best practices and go make their logic look the same and act the same.

that is the true horror at hand!

“Bad” is relative – it’s better than other styles I’ve seen. It could all be jammed in a code-behind.

Have you _seen_ the cover graphic that article had? I don’t have that kind of talent!

That article was already written, many times over, over the past couple of years. Check out the recent articles in the MSDN magazine.

So much pollution!!

It’s still a huge improvement over everything in the code-behind though.

I would, however, change the cache key creation so that I don’t get the cached results for 1, 15 when I ask for 11, 5.