MVC Core Repository Pattern for Multiple Lookup tables

Question

We have Customer transactional table with multiple lookup tables with foreign keys. We want to create dropdown menus using these lookup tables, when CustomerService creates a Customer order transaction. If a person views the transactions later, they would see the 4 tables joined together.

Would I create

(a) 4 interfaces with 4 repositories,

(b) or 2 interfaces (1 for Customer Transaction, 1 interface for the lookup tables), with 1 Repository for Customer Transaction, and 3 repositories for lookup table interface?

We want to relay Lookup table Repository to the SelectList below. Each select list is picking certain columns. Want to be efficient in code.

Models:

public class CustomerTransaction
{
    public int CustomerTransactionId{ get; set; },
    public int ProductTypeId {get; set; }, //joins to ProductTypeTable
    public int StatusKey {get; set; },  //joins to StatusTypeTable
    public int CustomerTypeId {get; set; } //joins to CustomerTypeTable
    public string DateOfPurchase{ get; set; },
    public string PurchaseAmount { get; set; },
}

public class ProductType
{
    public int ProductTypeId{ get; set; }
    public int Size { get; set; }
    public int Weight { get; set; },
    public string ProductName { get; set; },
    public string ProductDescription { get; set; },
}

public class StatusType
{
    public int StatusKey{ get; set; }
    public string Description{ get; set; },
    public string Symbol { get; set; },
}

public class CustomerType
{
    public int KeyNumber{ get; set; },
    public int Height{ get; set; }
    public string HairColor{ get; set; },
    public string NameOfPerson{ get; set; },
    public string ResearchNotes{ get; set; },
}

Required fieldsin dropdown

ViewData["ProductTypeId"] = new SelectList(_context.ProductType, "ProductName", "ProductDescription");

ViewData["KeyNumber"] = new SelectList(_context.CustomerType , "NameofPerson", "Description");

ViewData["StatusKey"] = new SelectList(_context.StatusType, "Symbol", "ResearchNotes");

Answer 1

If you don't need to insert, update or delete records in the lookup tables, don't bother with interfaces or concrete repositories allowing you to do that. Instead, add methods or properties to the customer transaction interface to get records from the lookup tables. This translates to additional properties on the repository interface:

public interface ICustomerTransactionRepository
{
    IEnumerable<ProductType> ProductTypes { get; }
    IEnumerable<StatusType> StatusTypes { get; }
    IEnumerable<CustomerType> CustomerTypes { get; }

    void Save(CustomerTransaction transaction);
    CustomerTransaction Find(int id);
}

You don't need 1 table per repository. A repository can provide access to all of the data relevant to a major entity in your system (or Bounded Context if you are applying Domain Driven Design principles).

By exposing IEnumerable<T> properties for the lookup tables on the customer transaction repository interface you have the ability to retrieve those records from the database to fill drop downs with options. You can also pass this 1 repository object around in your application's service layer and it is functionally complete, with regard to anything you need to do with customer transactions. Access to the lookup table data, plus CRUD operations for customer transactions, makes this "functionally complete."

If you really wanted to separate things, you could split your repository interface into two. One for getting data, and one for modifying data:

public interface ICustomerTransactionRepository
    : IWriteOnlyCustomerTransactionRepository,
      IReadOnlyCustomerTransactionRepository
{
}

public interface IReadOnlyCustomerTransactionRepository
{
    IEnumerable<ProductType> ProductTypes { get; }
    IEnumerable<StatusType> StatusTypes { get; }
    IEnumerable<CustomerType> CustomerTypes { get; }

    CustomerTransaction Find(int id);
}

public interface IWriteOnlyCustomerTransactionRepository
{
    void Save(CustomerTransaction transaction);
}

Then you can pass an interface around that is tightly focused on retrieving information or modifying it. You can still create 1 interface that inherits both, and implement this in 1 class, but at least it gives you some separation of concerns (and the "I" in SOLID: the Interface Segregation principal).