Active Records vs. Repository - pros and cons?

Viewed 11478

Using ActiveRecord you might define a class like this:

class Contact
{
  private String _name;
  public String Name
  {
    get { return _name; }
    set 
    { 
      if (value == String.IsNullOrWhiteSpace())
        throw new ArgumentException(...);
      else
        _name = value;
    }
  }

  public Boolean Validate() { ... /* check Name is unique in DB */  }

  public Boolean Save() { ... }

  public static List<Contact> Load() { ... }
}

Whilst this is nice and simple, I've found my classes become very bloated with a big mix of logic going on!

Using a layered/domain design you might define the same class like:

class Contact
{
    [Required(AllowEmptyStrings=false)]
    public String Name { get; set; }
}

class ContactService : IService
{
    public List<Contact> LoadContacts() { return (new ContactRepository()).GetAll(); }
    public Contact LoadContact(int id) { return (new ContactRepository()).GetById(id); }
    public Boolean SaveContact(Contact contact)
    {
        if (new ContactValidator().Validate(contact))
            new ContactRepository().Save(contact);
    }
}

class ContactRepository : IRepository
{
    public List<Contact> GetAll() { ... }
    public Contact GetById(int Id) { ... }
    public Boolean Save(Contact contact) { ... }
}

class ContactValidator : IValidator
{
    public Boolean Validate(Contact contact) { ... /* check Name is unique in DB */ }
}

class UnitOfWork : IUnitOfWork
{
    IRepository _contacts = null;
    public UnitOfWork(IRepository contacts) { _contacts = contacts; }
    public Commit() { _contacts.Save(); }
}

How was it migrated from Active Record => layered design?

  • Entity level validation in the Name setter => remains (ableit via a DataAnnotation)
  • Business logic/rule validation (unique Name) => moved from entity into a new separate ContactValidator
  • Save logic => moved to a separate Repository pattern class (also with a UnitOfWork)
  • Load logic => moved to the separate Repository
  • Interaction with the Repository is via a new ContactService (which will enforce use of ContactValidator, ContactRepository, UnitOfWork, etc - opposed to letting the caller loose with the ContactRepository!).

I'm looking for peer approval/suggestions for this layered design - I don't usually design outside of Active Record type! Any comment appreciated.

NB - This example is deliberately simple (the UnitOfWork isn't really used and the newing of Repository/Validator would be handled differently).

3 Answers

This article seems like a good and succinct description of both: https://hashnode.com/post/which-design-pattern-do-you-prefer-active-record-or-repository-cilozoaa5016o6t53mhsdu6nu

One thing I would like to add is it isn't just "active record is good when your persistence needs are simple and repository is good when your persistence needs are complex". The choice of pattern here has a lot more to do with how you feel about the Law of Demeter. If you want different parts of your architecture to be completely separated so that someone can understand one part without understanding another then you want the Law of Demeter. That said I think, especially early on in a project when the spec is likely to change, it is VERY dangerous to get too obsessive about these sorts of abstraction. Don't second guess your project's future maintainers, they might be smart and they should be able to think about more than one thing at a time and if they can't then you might have larger problems that cannot be prevented by using the Repository pattern.

Related