Abstracting user interface from domain

Question

My course text suggests creating a 'facade' class to completely abstract the user interface from the domain layer. That is, the UI uses only basic types, and if it needs a reference to a domain object, it only knows it as an Object.

To give you an idea, this is what it might look like (example in Java but could equally apply to other languages):

public class Facade
{
    ...
    public Object getLastOrder(Object customer)
    {
        Customer castCustomer = (Customer)customer;
        Order lastOrder = domainController.getLastOrder(castCustomer);
        return lastOrder;
    }
}

Note: I'm not sure whether this is in fact a type of facade pattern (I've heard it defined differently elsewhere), but I don't want to get too bogged down in terminology.

Compared to nothing (having the UI call the domain controller directly), I can see that this has the advantage that the UI is much more independent of changes to the domain model implementation. There's always a risk that very major changes (such as not having anything representing an order any more) will break things, but this seems to be able to absorb anything else.

However, it seems to sacrifice type checking, and it means that getting even simple properties of domain objects more convoluted than it needs to be (anOrder.getNumber() vs facade.getOrderNumber(anOrder)).

---

My own thought was that it would be better for the UI to reference domain objects in terms of interfaces, rather than plain Objects. For example:

public class Facade
{
    ...
    public IOrder getLastOrder(ICustomer customer)
    {
        Customer castCustomer = (Customer)customer;
        Order lastOrder = domainController.getLastOrder(castCustomer);
        return lastOrder;
    }
}

or even if the domain controller itself exposed only the interface types, forgetting the 'facade' altogether.

As far as I can see, this is better from a type checking point of view. Major changes (e.g. removing Order from the system) can break things, but that was true of the 'plain Object' solution.

And any methods that are stable (e.g. anOrder.getNumber()) can be specified in the interfaces, so calling them from the UI is simpler and more object-orientated. Obviously this only applies to methods whose signatures are stable, to avoid breaking the UI, but the implementation is still free to change.

Is there something I'm missing? Does my 'interface' solution have any drawbacks I haven't spotted? Or is there a completely different, better solution that I haven't though of?

Answer 1

I would advise you to use viewmodel classes for your UI instead of domain objects. There tends to be a large difference between the representation of data that your view needs and the representation of data that the domain needs.
Say you want to show a list of orders in the UI. An Order in the domain will probably have a lot of properties, some reference objects, etc. You'll probably not need most of those things in the UI, so just take what you do need, shove it into a viewmodel and bind that viewmodel to the UI.

PS: a facade is used to simplify working with one or more objects. If you want to achieve something and to do that, you'd have to make 5 calls to 5 different objects, a facade's responsibility would be to encapsulate those 5 calls, shielding you from the complexity of working with those 5 different objects.

Answer 2

Advantage of the first version:

• your API won't change, and it will be super-stable as it cannot be more general: public Anything DoSomething(Anything something) { }

Disadvantage:

• the caller should always guess and cast your return value. What if the developer won't check your documentation and does this:

  if ((bool)yourObject.getLastOrder(customer)) { ... }

• you are where you are started: both the caller and the function depends on the Customer concrete class. It is just hidden from the signature, so you introduce a new level of failure: what happens when you write the following totally logical code:

  Company theirCompany = MyDb.GetCompany(12345); Order order = (Order)yourObject.getLastOrder(theirCompany);

  You still have to check every single call if Customer class changes. You made matter worse by replacing all concrete types with object. There is a level when you cannot be more abstract and you are making more work for yourself.

If you have a program for handling orders you cannot prepare it to make only very little changes where you are not handling orders anymore... But you can prepare if there will be new types of orders and customers.

Given that, the only useful level of abstraction you can have here is to find out what is the minimal amount of information you need in your function/class about getting an order.

So, you slicing that information from your ICustomer interface. For orders you'll have, say, an ICustomerID interface:

public interface ICustomerID { int getID(); }

public interface ICustomer : ICustomerID { ... } 

public interface ICompany : ICustomerID { ... }

So back to your function:

public IOrder getLatestOrder(ICustomerID id) { /* get order */ }

And calling would look like this:

Customer customer = SomeFactory.GetCustomer(...);
Company company = SomeOtherFactory.GetCompany(...);

IOrder customerOrder = myObject.getLatestOrder(customer);
IOrder companyOrder = myObject.getLatestOrder(company);

You can have two totally different interface for Customer and Company; you can change their implementations any time; you won't have to change getLatestOrder.