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

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.

Answer 2

I think you're implementing a domain model and a data-access object. It's a good idea.

Answer 3

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 4

It looks like it could be the repository pattern this seems to be an increasingly common pattern and is used to great affect in Rob Conery's Storefront example Asp.Net MVC app.

You're basically abstracting your data access code away from the Model, which is a good thing, generally. Though I would hope for a little guts to the model class. Also from previous experience, calling it Users is confusing, UserRepository might be beter. Also might want to consider removing static (which is a hot debate) but makes mocking easier. Plus the repository should be implementing an interface so you can mock it and hence replace it with a fake later.

Answer 5

It's not really object-oriented in any sense, since the object is nothing but a clump of data sticking together. Not that that's a terrible thing.

Answer 6

The first class is anti-OOP because it contains data without behaviour, a typical example of an anemic domain model. It's typical for people who do procedural programming in an OO language.

However, opinions are devided on whether it makes sense ot put DB access logic into the domain model itself (active record pattern) or, as in your code, into a separate class (Data Access Object pattern), since DB access is a separate technical concern that should not necessarily be closely coupled with the domain model.