5

TLDR; I have one repo interface and multiple data sources, each with a different data identifier - how can I maintain having only one method in my interface?

I have a need to read a domain object OrderData from two different repositories: one is an outside service and the other one is a local database. Let's call them OutsideServiceOrderRepo and LocalDbOrderRepo. They both implement an interface called IOrderRepoRead:

Interface IOrderRepoRead
  +GetOrder(OrderEntityData) : Order

I'll never use both implementations in the same use case, it's an either/or situation. I have sorted out how to inject one or the other repo at the composition root, depending on the use case. The problem I have is that each of these data stores has a different identifier for the data I'm after:

  • Local store has a simple OrderId that I have within my system.
  • External service requires me to query using a person's Tax_number+Name+what_not etc...

The ideas I came up with so far are as follows:

  1. I have a type called OrderEntityData with properties TaxNumber, Name, OrderId. Both implementations can use this type, each implementation works with the properties it requires: OutsideServiceOrderRepo uses TaxNumber, Name, whereas LocalDbOrderRepo uses OrderId.
  2. I drop the OrderEntityData and have two different methods in my IOrderRepoRead.

.

Interface IOrderRepoRead
  +GetOrder(taxNumber, name, whatNot) : Order
  +GetOrder(orderId) : Order

I'm inclined to go with approach #1, but it still feels like there is a certain amount of coupling among the repo and client code.

How can I efficiently alternate between different identifiers?

  • why do you want to get by OrderId in your local use case? – Ewan Jan 16 '18 at 16:24
  • Why not have two interfaces? Try and build interfaces to satisfy your consumers, rather than building interfaces to some preconceived design and then forcing consumers into them. – Ant P Jan 16 '18 at 16:46
  • @Ewan: Local data store identifies by orderId while the external data store identifies orders by taxNumber, name, whatNot. Why do we have the same order in two different data stores? Think of it as the order's lifecycle: they start their life in our local data store, get approved and then we move them to the external data store. – robotron Jan 16 '18 at 16:46
  • @AntP: It somehow seems bad design to have two interfaces for the same domain model, each interface doing what is in essence the same thing: persisting the order. – robotron Jan 16 '18 at 16:48
  • 2
    Technically isn't GetOrder(taxNumber, name, whatNot) a finder? If so, I would opt for #2 can call that method FindOrder(taxNumber, name, whatNot). The concepts are different. One is you have a unique identifier to get that specific record. The other is to find a record (or records) that match your criteria. – Berin Loritsch Jan 16 '18 at 16:51
4

It seems to me that the two services are not the same thing.

If taxNumber, name, whatNot produce a unique id, then you can join em all together, use that as your orderId and have the same GetOrder(taxNumber, name, whatNot) locally as the service.

If they do not, then the external service and your local repository are not implementing the same interface. One gets a unique record and one searches for matches.

You shouldn't attempt to join the two, because even if you manage it with some clever code the Business logic isn't the same. Have:

Interface IOrderSearcher
  +GetOrder(taxNumber, name, whatNot) : Order

Interface IOrderRepository
  +GetOrder(orderId) : Order

Your local repository can implement both if required.

  • I've analyzed my use cases again and have decided to go with this approach, since it supports the use case/application flow nicely. I consider other answer to be of high quality as well, but this one nailed it on the head. Thank you for your assistance. – robotron Jan 31 '18 at 10:10
  • Just to be clear, I went with the second approach: interface segregation to better support the client needs (IOrderSearcher and IOrderRepository). – robotron Jan 31 '18 at 10:11
3

There is nothing wrong with approach number 2, and in fact this is the approach I've seen the most. Approach #1 could work as long as you lean on encapsulation to limit how clients can use this "order entity finder object":

public class OrderIdentifier
{
    public int OrderId { get; private set; }
    public string TaxNumber { get; private set; }
    public string Name { get; private set; }
    public string WhatNot { get; private set; }

    public OrderLookupMethod LookupMethod
    {
        get => OrderId > 0 ? OrderLookupMethod.ById : OrderLookupMethod.ByTaxInfo;
    }

    public OrderIdentifier(int orderId)
    {
        OrderId = orderId;
    }

    public OrderIdentifier(string taxNumber, string name, string whatNot)
    {
        // ...
    }
}

public enum OrderLookupMethod
{
    ById = 0,
    ByTaxInfo = 1
}

And then in your repository:

public Order GetOrder(OrderIdentifier id)
{
    Order order = null;

    switch (id.LookupMethod)
    {
        case OrderLookupMethod.ById:
            order = // Find by Id
        case OrderLookupMethod.ByTaxInfo:
            order = // Find by tax info
        default:
            throw new ArgumentException(...);
    }

    return order;
}

The combination of the two constructors and making the setters private for the OrderIdentifier class ensures clients instantiate this correctly:

OrderIdentifier byId = new OrderIdentifier(4); // Find by Id
OrderIdentifier byTaxInfo = new OrderIdentifier(taxNumber, name, whatNot); // Find by tax info
2

If you're looking for the simplest solution from your current point, the "two methods and a conditional" option works just fine.

If you're looking for a more elegant, polymorphic solution, without passing redundant parameters, then here are a couple of approaches you could consider.

What you really have is two different implementations of an IOrderQuery interface (or whatever you prefer to call it). The trouble is that those implementations need different constructor parameters, supplied at request time and your composition is done in your application's root.

You can solve that problem with a factory.

public class InternalOrderQuery : IOrderQuery {
    public InternalOrderQuery(string orderId) { ... }

    public Order Get() { // fetch order by ID }
}

public class ExternalOrderQuery : IOrderQuery {
    public ExternalOrderQuery(string taxNumber, string name, ...) { ... }

    public Order Get() { // fetch order by things }
}

public interface IOrderQuery {
   Order Get();
}

public class OrderQueryFactory {
    public IOrderQuery Create(RequestData stuff) { ... }
}

Inject the factory and, in Create, create the order query as appropriate - the rest of your code doesn't know the difference.

Alternatively, your first approach works well but can benefit from better encapsulation:

public class OrderRequest {

    private String name;
    private String taxNumber;
    private String orderId;

    public OrderRequest( ... ) { // assign fields }

    public Order Execute(IOrderRequestContext context) {
        return context.Get(name, taxNumber, orderId);
    }
}

Implement IOrderRequestContext twice - once to execute against the remote DB and once against the local.

You could take this further and make the request parameters key/value pairs - that way the context can just read what it needs without needing you to explicitly define every possible parameter for every possible implementation.

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.