How would you classify this type of design for classes?

Question

The following type of design I have seen basically has "thin" classes, excluding any type of behaviour. A secondary class is used to insert/update/delete/get.

Is this wrong? Is it anti OOP?

User.cs

public class User
{

    public string Username { get; set; }
    public string Password { get; set; }
}


Users.cs


public class Users
{
    public static User LoadUser(int userID)
    {
            DBProvider db = new DBProvider();
            return dp.LoadUser(userID);

        }

}

Answer 1

While your user.cs class is lending itself towards a domain transfer object, the Users.cs class is essentially where you can apply business rules within the data-access objects.

You may want to think about the naming convention of your classes along with the namespaces. When I look at a users.cs, I'm assuming that it will essentially be a class for working with a list of users.

Another option would be to look into the Active Record Pattern, which would combine the two classes that you've created.

User.cs

public class User
{
    public string Username { get; set; }
    public string Password { get; set; }

    public User(int userID)
    {
        //data connection
        //get records
        this.Username = datarecord["username"];
        this.Password = datarecord["password"];
    }
}

Answer 2

I would classify it as a domain object or business object. One benefit of this kind of design is that it keeps the model agnostic of any business logic and they can be reused in different kind of environments.

The second class could be classified as a DAO (Data Access Object).

This pattern is not anti-oop at all and is widely used.