Question

In repository examples, I see the repository instantiated when the Session opens, which seems as if it is around for the entire Session. In controller actions, the data layer is then accessed through calls to the repository. Is this common practice? Wouldn’t it make more sense to be instantiating the repository in an on need basis per action request?

Edit: A more exact scenario.

public class myController : Controller {
  IMyRepository myRepository;

  public myController(IMyRepository repositoryParam){
    myRepository = repositoryParam;
  }

  public ActionResult someAction(){
    MyClass myClass = myRepository.RepositoryAction();
  }
}

In this scenario, myRepository is global to myController (note: this is based off an example from Steven Sanderson). I have seen it also defined for all controllers to access, but this is a simple, exact, example. In this example, why would the repository be used globally instead of on a per use basis?

Answer 1

To answer your question, Travis, you should read up a bit on the Repository Pattern. This pattern is used to provide a number of advantages, including:

• It centralizes the data logic or Web service access logic.
• It provides a substitution point for the unit tests.
• It provides a flexible architecture that can be adapted as the overall design of the application evolves.

As to your question: “Is this a common practice?” the answer is, “It should be.” but, unfortunately, I don’t see it as much as I would prefer.

Now, in your example, you show the repository being created within the context of your controller class. (Please note that this is NOT the same thing as an object being made “global” as you put it. Global means that the object is accessible from any scope. Read more about it here at Wikipedia.)

In any case, one of the advantages is that the repository allows you to change between how you are accessing your data (or even where your data is being accessed) by using the correct, concrete version of the repository. So, you may have:

• IRepository – Your interface which the concrete repositories implement.
• DatabaseRepository – Accesses your data in a database.
• FlatFileRepository – Access your data out of a flat file.
• etc.

If you wish to switch to other data sources, it is a simple as swapping out the concrete implementation in your controller. (Please note, there are more advanced and flexible ways of doing this through dependency injection, but that is out of scope of this question, although it does/can play heavily in the repository pattern.)

In any case, say your project team decides “Hey, we’re going to switch from storing all our data in flat files to using a database.” Well, if you have scattered the instantiations of that specific repository throughout your code, you now have a lot of different areas to fix and update, somewhat negating the advantages of the repository pattern. However, by declaring a member repository of your controller, you just switch from a FlatFileRepository to a DatabaseRepository, implement the new repository, and you are finished! Everybody on the team is happy!

Update: “Why Instantiate a Class Variable?”

To answer that question, you have to think of your two options. The first option is that you could hold a relatively small object in memory. The other alternative is you could instantiate a new object in memory every time that a user needs to access one of your actions causing new memory to be allocated (and deallocated when you leave the scope that the object was in) and requiring more work by the server which is hosting your web app.

If you think about how a website is used, users are hitting those actions on a frequent basis. Every action signifies a portion of your website. If you instantiated every single time you needed the repository, you would quickly give the server a much bigger workload than it actually needs – particularly as your site grows in size. (I am sure other folks can think of other reasons why you would want to do it the way shown in the tutorial vs. instantiation in each individual action.)

And, then, of course, there is the refactoring issue as I mentioned above. That is about “efficiency of making changes” or improving the maintainability.

Hope that helps you a bit more and better answers your question!