Serializable PagedList for .NET

Developers have to page through data sets every day. For example: bring me back 101-200 (or the second page) of 1,000 results. So how do we move that data between our data, service, and UI and layers? That is where a PagedList collection comes in!

The sooner you add this to your core library the better off your whole team will all be. No more creating extra models to hold page data, no more loading extra results just to pass that data around and then not consume it, and no more reinventing the wheel over and over! I really wish that Microsoft would add a native paged list to the .NET framework; but until that time we just have to roll our own.

So what are the qualities of a good PagedList?

• It should be generic collection.
• It should support a non generic interface.
• It should be easy to serialize.

Yes, there is already a PagedList project on NuGet and GitHub. Please do not misunderstand me, that is a good project! However the code below is a bit more light weight and easier to serialize. Additionally I prefer the extension methods of ToPagedList and TakePage; where the former creates a list as a page, and the latter selects a page from a super-set.

But hey, you can decide which you prefer! :)

Interfaces

public interface IPagedList

{

    ICollection Items { get; }

    int Count { get; }

    int PageIndex { get; }

    int PageSize { get; }

    int TotalCount { get; }

    int TotalPages { get; }

    bool HasPreviousPage { get; }

    bool HasNextPage { get; }

}

public interface IPagedList<T>: IPagedList

{

    new ICollection<T> Items { get; }

}

Sharing Generic Configuration Across Projects

When you work with a team of developers on a large application across multiple projects, everyone is going to need access to unique configuration settings. Often this will give rise to each project having it's own separate configuration services, or worse everyone will just call the static ConfiguationManager directly.

How do you share a single configuration object across projects?

The answer is simple: extension methods! Just create a generic configuration service in your core library, and then have all of your other projects call it via extension methods. This ensures that you only have one testable, injectable, and extensible source for configuration. Additionally it keeps all of your configuration both discoverable and abstracted to their consuming project.

public interface IConfigService

{

    T Get<T>(string key);

    T Get<T>(string key, T defaultValue);

}

public static class ConfigServiceExtensions

{

    private const string NotificationsKey = "AreNotificationsEnabled";

    private const bool NotificationsDefault = true;

    public static bool AreNotificationsEnabled(this IConfigService config)

    {

        return config.Get(NotificationsKey, NotificationsDefault);

    }

}

Remember, every project can have it's own set of ConfigService extension methods. :)

Dependency Injection with SignalR and MVC

Thank you to Isaac Abraham for bringing this solution to my attention!

Do not extend DefaultDependencyResolver

How do you practice inversion of control with SignalR? The official SignalR documentation suggests that you extend the DefaultDependencyResolver base class, and then register that as SignalRs dependency resolver.

This however, can have some nasty side effects! In my case, the ConnectionManager.GetHubContext method was not properly resolving my contexts, and thus I was unable to broadcast messages to my hubs clients.

So then, what is a less obtrusive way to inject your dependencies into your hubs?

Instead register an IHubActivator with the DependencyResolver

A simpler solution is just to register a custom HubActivator with the already existing DependencyResolver. This means that instead of completely replacing the SignalR resolver you are instead adding to it.

The HubActivator is only used when trying to resolve a hub; thus the activator can wrap your container of choice and use it to resolve your hub with its dependencies, while leaving the rest of the SignalR pipeline intact.

SignalR Startup with MVC DepenencyResolver

What does this all mean? It means that once you have your dependency injection setup for MVC, you can then create hubs with dependencies using the same container! This MvcHubActivator will use the default System.Web.Mvc.DependencyResolver to resolve its Hubs:

Blogging Schedule for 2014

It is amazing to me that I have been blogger for five years now! I am very proud that for the past two years I upheld the standard of writing at least two posts per month, and for the past six months I have doubled that with four posts per month.

Next year I am going to throttle my tech articles back down to three per month, and try to diversify my efforts a bit more...

• www.TomDuPont.net
  • Three Tech Articles per Month
• www.QQ-Cast.com
  • Two "Quest" Podcasts per Month
  • *NEW* Two "News" Podcasts per Month
  • One Written "QQ Review" per Month
  • *NEW* One Video "Let's QQ" per Month

Obviously, this is a VERY aggressive content schedule! The videos are something that I used to do professionally, and now I want to get back into them for just for fun. Regardless of everything else, my highest priority will be to maintain the technical articles on this site.

Happy New Year,
Tom