interfaces and dependency injection correct use in C#

Question

I have an interface "IUser" and a class "User" implementing "IUser". Also I have an interface for the repository "IUserRepository".

I'm between these two options:

public interface IUserRepository
{
    List<User> getAll();
    void addUser(User user);
    void alterUser(User user);
    void deleteUser(string ID);
    bool validateLogin(string session_user, string session_pass);
    User getUserByID(int ID);
    User getUserByNombre(string name);
    User getUserBySessionUser(string session_user);
}

and this

public interface IUserRepository
{
    List<IUser> getAll();
    void addUser(IUser user);
    void alterUser(IUser user);
    void deleteUser(string ID);
    bool validateLogin(string session_user, string session_pass);
    IUser getUserByID(int ID);
    IUser getUserByNombre(string name);
    IUser getUserBySessionUser(string session_user);
}

Here is my confusion. Should my methods in the repository interface return real implementations or interfaces? as you can see in my first option I'm returning "User" instances. What I should return to loosely couple the code?

But if I choose the second one in my real implementation of the user repository I will only have access to the methods and properties that I had declared in my IUser interface.

for example if I call addUser method from a service passing it an instance of User class:

   myRepositoryImplementation.addUser(UserInstance);

then my real repository is going to like this

  private readonly IUser user;
  public void addUser(IUser _user)
  {
    this.user=_user;
  }

Nice valid catch! but then I will only have access to the method and properties declared initially in the IUser interface and not of any new method or property declared in my User instance.

also if I call getUserByID method I will receive an IUser instance.

So to resume this

1). Are these valid approaches?
2). If these are valid approaches which one should I use to preserve or keep the code decoupled?
3). If I choose the second one also if it is valid then should I declare in the interface all I'm going to use later? I mean properties and methods?
3). Have a better idea?

CR.SE is about reviewing working pieces of code, while this is more of a high-level design question. This could, however, be a decent fit for programmers.SE — Dan Lyons, Sep 05 '14 at 17:45
The point of an interface is to expose properties and methods for other code to use, if you make an IUser inferface it should have all the stuff you need in it. — reggaeguitar, Sep 05 '14 at 22:05

score 2 · Answer 1 · edited May 23 '17 at 12:00

I'd definitely go with the first option. Having an interface for a service class like a repository is useful, but for an entity class like User, not so much.

As you said, every time you would add a property, you would also need to add the property to the Interface, which is tedious. And assuming that your user class is a simple class without dependencies to other classes, it is easily testable even without an Interface.

Related reading:

http://lostechies.com/jamesgregory/2009/05/09/entity-interface-anti-pattern/

Interfaces on entities are an anti-pattern -- James Gregory blog

Should entities implement interfaces?

score 2 · Accepted Answer · answered Sep 05 '14 at 17:49

1) yes, both are valid

3) yes, properties and methods

2) a little longer story. in short, if you have POCO classes and you are 100% sure you are never going to code against a framework that doesn't allow you to use POCOs (e.g. instead, it insists on classes inheriting from a framework-specific base class), you could go with the first option (classes).

But it not always works.

For example, coding your repositories for Linq2SQL and other repositories for Entity Framework Code First, you can't use the very same set of classes. The second (interface) approach is the only option. We've succesfully used it in several enterprise applications with no issues.

A word of advice - if you go with the interface approach, you definitely need a method to create an empty instance

public interface IUserRepository
{
    List<IUser> getAll();
    ...
    IUser CreateNew();
}

Otherwise the repository client has no other means of creating an instance of a concrete type - the type is unknown to the client. Some people tend to move the creation method to a separate factory class, though.

clhereistian · Answer 3 · 2014-09-05T17:51:15.723

I think part of your confusion is that you have methods in your User class. Normally these type of model classes only represent data, and do not describe behavior. So, if you moved your methods somewhere more appropriate, your whole confusion would disappear because there would be no reason for an interface.

In other words, move the methods out of the User class and have your repo work like:

List<User> getAll();

interfaces and dependency injection correct use in C#

3 Answers3