4

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");
1
+50

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).

  • Hi Greg, I am trying to understand (Crud consists of Reading, Create-Read-Update-Delete), so you mentioned to separate read operations for the lookup tables from customer transaction repository (first sentence), then on second sentence, to place Read retrieval methods for lookup tables on the customer transaction table, so which one is it? If I have a create, update, or delete, should I only then creating a repository for lookups? Thanks, – SkyPool392 May 24 '18 at 19:28
  • 1
    @BlueLamp82: I'll clarify my answer. – Greg Burghardt May 24 '18 at 19:33
  • @BlueLamp82: updated my answer. Hope this helps. – Greg Burghardt May 24 '18 at 19:40

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.