Generic factory with repositories: Part 1

This post is part of a series:
- Generic factory and repositories: Part 2 revisited
- Generic factory and repositories: Part 2
- Generic factory and repositories: Part 1
- WCSF, Repositories and Unit of Work?

My previous post was about using WCSF in combination with repositories and a unit of work. I didn’t have any clear answers then and I don’t have any clear answers now. It doesn’t matter any more though, since I decided to drop WCSF entirely and pursue my own implementation of a modular web application, based on MVP, where I can still use my repositories as I would like.

The reasons why I’m doing this don’t matter. It has some very solid grounds, but I won’t discuss them as it’s not in the scope of this post.

Let’s take a look at the situation I’m faced with for a new proof of concept project:

I need to be able to make a simple modular web application. Users would need to be able to enter meeting-reports as well as enter activities. However, some issues in the meeting will have led to activities needing to be completed. So it should also be possible to create activities when entering a meeting-report.

In this case I will have two modules in my system: MeetingReports and Activities. The MeetingReports module will need to use the ActivitiesRepository within the Activities module to be able to create activities.

I won’t go into details, but WCSF had this nicely covered by working with dependency injection and interface libraries. That’s a practice from WCSF that I would like to adapt. However, I can’t simply make a reference from MeetingReports to the activties interfaces. I will have to instantiate a concrete class at some point!

What if I would be able to make a generic factory that instantiates repositories for me and returns their interface? I would be able to use the repositories without needing to know anything about their implementations.

I don’t have any concrete code yet (what a surprise!), but I would imagine something similar to this might be very possible:

using (IUnitOfWork uof = new UnitOfWork)
{
    IMeetingReportRepository irr =
        RepositoryFactory.Create<IMeetingReportRepository>(uof);
    irr.Insert(meetingReport);

    IActionRepository iar =
        RepositoryFactory.Create<IActionRepository>(uof);

    // Save all activities.
    foreach (Activity a in meetingReport.Activities)
    {
        iar.Insert(a);
    }

    uof.Commit();
}

The factory class would know how to instantiate ActionRepository based on the fact that its create method has been called with an IActionRepository generic! This way the factory will do the concrete instantiation while the activities module will only see, and use, the interface!

Hopefully I will be able to show some working C#-code soon, so stay tuned (yes, again)…

• «Previous Post
• Next Post »