Repository pattern vs DTO pattern approach

Question

We can have these two approaches to send data to Data Access Layer or any other source:

Approach 1: Repository way:

public class User
{
    public string FirstName { get; set; }
    public string LastName { get; set; }
    public int Age { get; set; }
}

public class UserRepository
{
    public static void Add(User user)
    {
        // Add user logic
    }
    public static void Delete(User user)
    {
        // Delete user logic
    }
    public static User Get(int userid)
    {
        // Get user logic
    }
}

Usage:

var user = new User
    {
        FirstName = "FirstName",
        LastName = "LastName",
        Age = 20
    };
UserRepository.Add(user);

Above, you have seen that I have kept the User class simple. It is not having any behavior.The behavior is added in a separate class UserRepository.

Second approach: Keeping Add/Delete/Get etc in User.cs only:

   public class User
    {
        public string FirstName { get; set; }
        public string LastName { get; set; }
        public int Age { get; set; }

        public void Add()
        {
            // Add user logic
        }
        public void Delete()
        {
            // Delete user logic
        }
        public User Get()
        {
            // Get user logic
        }
    }

Usage:

var user = new User
    {
        FirstName = "FirstName",
        LastName = "LastName",
        Age = 20
    };
user.Add();

Above I have kept the behavior in User.cs only. Both of the two approaches is serving the purpose of adding, deleting etc. the user. Can you let me know

Which approach is better?
When to decide which of the above two approach we have to opt?
If I have to add other methods too like FindAllUsers, FindUserByUserId, DeleteUserByUserId which approach should I go for?

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

The first approach is far better as you are separating concerns i.e. the domain entity User and persistence to the database.

One of the most important things that is often talked about in Domain Driven Design is "persistence ignorance" See What are the benefits of Persistence Ignorance?

By using the repository pattern, the way you save /get your entity is kept out of the entity code, i.e. your domain keeping it cleaner and in essence achieving persistence ignorance (or going a long way towards it anyway)

So answers:

The repository approch is much better
Always go for option 1
Add these methods to the repository class

+1 Just to add to this - using the repository pattern carries much more clarity - The repository *adds* users, users don't *add* themselves. — James, Aug 28 '12 at 11:06

score 1 · Answer 2 · answered Aug 28 '12 at 11:01

It strictly depends on the work you need to get done and on the size of your app. If you want something developed fast and less scalable you don't need to use a n-tier type architecture(i mean separate your data interactions to your Data acces layer).

However if you are looking for something that need to be highly scalable, editable, modifiable and know that it will get future features then clearly you must separate your consceurns to make your work easier for a longer period of time.

In the end as i said each approach serves a purpose, just know what your purpose is before getting to work.

Cheers.

Hooman Bahreini · Answer 3 · 2020-05-19T23:18:42.697

If you follow DDD guidelines, then, entities should NOT have dependency on infrastructure:

Nikola’s 1st law of IoC

Store in IoC container only services. Do not store any entities.

Reason: By including infrastructure logic into your entity, you are moving away from Single Responsibility Principle. See Mark Seemann's explanation.

The problem with your second approach is that User Entity has dependency on Infrastructure.

Repository pattern vs DTO pattern approach

3 Answers3