1. Just to check your not storing the GUID references in your static class? Are these just properties that locate these pages? With about a decade of CMS experience I would never ever hardcode a page reference in any CMS platform, you should put them in a configuration section and load them from there so they can always be updated.
2. In my opinion there should be no static classes apart from extension methods. Separating out to a service arcitecture support better separation and also the ability to using mocking for unit tests. If any services you unit testing relied on this static class but you were swapped out the data layer you would not be able. So for testing it's always better to seprate
3. Injected<T> is an anti pattern as it uses ServiceLocation under the hook which is bad. You should try to always use constructor injection, this will also identify issues with circular dependancies. 

There are several problems with Injected<T> and ServiceLocator - mostly they hide the dependencies from outside. Also they make the class almost impossible to test (unless you mess with the service registration, and I can tell you that can be very messy)

I kinda disargee with Scott on 2. point. static helper classes can be useful if they only serve as true "static", i.e. no state. Of course that's when you have to decide between static helper class and singleton, but that's pretty much your taste. If your static helper class does not prevent its consumer classes from being unit tested (mocking etc.) then it's fine for me. 

Let me clarify, if a static class just had a load of constants in it or extension methods that's acceptable. But I wouldn't personally want any methods in static classes, I would want them all in services and injected. Our solutions used to be littered with static helpers and they were a mess to test. 

Doing dependency injection and making helper classes instead of writing C# code in razor views may seem like overkill to some developers.

However, when developing Episerver solitions, we want to make sure our code works by writing unit tests, in addition to manual testing.

For example, when showing pages in the main navigation, it's not enough to do

_contentLoader.GetChildren<PageData>(ContentReference.StartPage).ToList().

We need to make sure we're not returning:

• pages without templates (container pages)
• unpublished pages
• restricted pages
• pages that have VisibleInMenu set to false

This is something that developers should test by mocking IServiceLocator, ITemplateResolver, IPublishedStateAssessor etc.

However, unit-testing may be difficult if the business logic is located inside static classes, razor views, etc.

When it comes to mocking ServiceLocator and Injected<T>... it takes just two lines of code:

var serviceLocatorMock = new Mock<IServiceLocator>();
ServiceLocator.SetLocator(serviceLocatorMock .Object);

However, mocking internal episerver stuff can be quite tricky.

Great guys, 

thank you for the clarification.

there is a trick to avoid ServiceLocator usage in extension methods to get access to the service required. You create extension method on the service. For example, not this:

pageData.GetSomeFancyExtenralUrl(..)

static GetSomeFancyExtenralUrl(this ContentData page, ...)
{
    var resolver = ServiceLocator.Current.GetInstance<UrlResolver>();
    ...
}

but you actually make an extension on `UrlResolver` instead:

resolver.GetSomeFancyExtenralUrl(pageData, ..)

static GetSomeFancyExtenralUrl(this UrlResolver resolver, ContentData page, ...)
{
    ...
}

and now you just have to solve the issue how you are going to get to the instance of the `UrlResolver` class. usually either you can go with `Injected<T>`, demand in constructor or do any other of the black magic to get access to.