3

I use repository pattern in my MVC applicaton. Each repository contains data retreiving methods such as GetByID, GetByXXXX, GetByYYYY. If i need to execute methods like these from controllers of the other entities, i need to instantiate that repository just for that operation. Do you think this way is expensive for the system? Should I or not make these methods static? Thank you!

Jim
  • 123
  • 1
  • 9

4 Answers4

1

You should not make them static. You should be using an IoC container to do dependency injection.

Here is an example with code: Entity Framework 4 CTP 4 / CTP 5 Generic Repository Pattern and Unit Testable

Post on useing IoC Containers: NuGet for Structuremap: http://nuget.org/List/Packages/StructureMap-MVC3

Blog post: http://www.bengtbe.com/blog/post/2009/02/27/Using-StructureMap-with-the-ASPNET-MVC-framework.aspx

Community
  • 1
  • 1
Paul
  • 12,392
  • 4
  • 48
  • 58
  • 1
    OMG, one more abstraction level? All good MVC appsshoul use DI/IoC? (I'm just starting with MVC...) – Jim Mar 29 '11 at 00:50
  • Getting started with MVC, take your time, implement as you see best. What worked for me was using IoC/DI, however, and it really helped to begin to separate the various pieces of code out into smaller, much more manageable units. Yes, it's an extra layer, and more to manage at first, but over the lifetime of an application, well worth the effort for maintainability. – reallyJim Mar 29 '11 at 02:32
  • 1
    @Jim - DI really has nothing to do with MVC. It is a part of S.O.L.I.D principles. You can learn more about S.O.L.I.D here: http://www.dimecasts.net/Casts/ByTag/SOLID%20Principle The D in S.O.L.I.D is Dependency Inversion Principle. I recommend watching the entire series. – Paul Mar 29 '11 at 02:40
1

Instantiating a Repository isn't an expensive operation especially when measured against the normal round trip time of a web request. If the repository is read only, there is no problem in using a static instance but if it's read-write, you'll need a separate repository for each request.

Michael Brown
  • 9,041
  • 1
  • 28
  • 37
  • How static GetXXX methods can interfere the rest of the repo? – Jim Mar 29 '11 at 00:57
  • 1
    @Jim, you obtain some state of your entities with those methods - thats why you'd better not make'em static. You can make method static if that doesn't deal with state - e.g. if you can easily move'em to separate static helper class. If not - most probably you deal with the state of repository and will not be able to make the context of the repo method call static. – Vasiliy R Mar 29 '11 at 07:46
1

Like we all say, I'd say "it depends.". Like Paul mentions in his answer, it's good to use Dependency Injection--but whether you do or not doesn't really have bearing on the core of your question.

I've put together several applications that do, but whether your code is using DI in the constructor

private ISomeInjectedType myRepository;
public SomeController(ISomeInjectedType type) 
{
    myRepository = type;
}

or just instantiating the type 

private ISomeType myRepository;
public SomeController() 
{
    myRepository = new SomeType();
}

You'll essentially get the same result out of the code--leaving maintainability out of the argument.

I've done this via the DI approach for a number of applications, and have found zero drawbacks from a performance standpoint--even when inadvertently having a team get a little out of control and wind up injecting/creating about 12 "repositories" that were created for each controller constructor.

Either way, whatever works best for you. You mentioned you were getting started with MVC. My thoughts on that are yes, use DI, but do it when you're ready.

Take the small steps you need to in order to get things up and running, then advance them as needed.

reallyJim
  • 1,336
  • 2
  • 16
  • 32
  • By the way, I like to think that with my example where not using DI, you're still setting yourself up for it when you're ready--by already having a single instance of the repository/repositories in the controller. – reallyJim Mar 29 '11 at 02:42
  • 1
    You should always use DI. If you don't want to use an IoC container then you should use poor mans DI. ie. public SomeController() : this(new SomeType()){} – Paul Mar 29 '11 at 02:55
  • @paul - I can already tell you and I would have some great discussions in person! +1 – reallyJim Mar 29 '11 at 03:02
  • Hello guys! I have repo interfaces for every repo and in my controllers I create and use those functionality only via intrfaces - as it was in NerdDinner. I only dont know why its called "DI" or "IoC" and how it can be helpful in other cases but changing actual repo object... :( – Jim Mar 29 '11 at 09:35
0

Repository instantiation isn't performance costly operation, nor creation of ORM session is (be it NHibernate ISession or EF ObjectContext). Don't make unnecessary micro-optimisations and arm yourself with an IoC tool to easily and transparently inject all repository dependencies (it is much simpler than it seems before you use it first time).

Static methods are no way helpful here bacause you are not dealing with a static context (you should have a concrete instance of your ORM Session - and that is a state - you're not able to use it in a static context).

Vasiliy R
  • 941
  • 8
  • 18