What is the advantage of using the facade along with MVC?

Question

Read about facade, but not quite understand the advantage to use, primarily using MVC. Could someone help me understand? Some more practical example? Excuse my ignorance!

Answer 1

The Facade Pattern is an aggregate service that provides several contextual features or services.

From Wikipedia

The facade pattern (or façade pattern) is a software design pattern commonly used with object-oriented programming. The name is by analogy to an architectural facade.

A facade is an object that provides a simplified interface to a larger body of code, such as a class library. A facade can:

• make a software library easier to use, understand and test, since the facade has convenient methods for common tasks;

• make the library more readable, for the same reason;

• reduce dependencies of outside code on the inner workings of a library, since most code uses the facade, thus allowing more flexibility in developing the system; wrap a poorly designed collection of APIs with a single well-designed API (as per task needs).

This being said, off the top of my head, let's say you have an accounting system for which the main form is an MDI, so you have multiple menus here and there allowing the user to access those functionalities.

In order to avoid multiple dependencies, instead of writing something like the following:

public class MainWindow : Form {
    public MainWindow(CustomerManagementPresenterFactory customerMgmt
        , SupplierManagementPresenterFactory supplierMgmt
        , InventoryManagementPresenterFactory inventoryMgmt
        , EmployeeManagementPresenterFactory employeeMgmt
        , StatementOfAccountManagementPresenterFactory statementOfAccntMgmt
        , InvoicesPastDueManagementPresenterFactory pastDueInvoicesMgmt) {
        // Work your dependencies here...
    }
}

where you clearly see that your MainWindow depends on multiple factories (or whatsoever), it is time to refactor. One question is:

• Do I have too many dependencies passed to my MainWindow constructor?

The answer is YES, I have. Despite, my MainWindow does need all those dependencies in order to fulfill its requirements.

• How can I refactor to reduce the number of dependencies?

One might state that the Past due invoices, Statement of accounts and the Customer management features shall be aggregated into only one service. Here comes the Facade.

public class CustomerManagement {
    public CustomerManagement(CustomerManagementPresenterFactory customerMgmt
        , StatementOfAccountManagementPresenterFactory statementOfAccntMgmt
        , InvoicesPastDueManagementPresenterFactory pastDueInvoicesMgmt) {
        // Work your dependencies here...
    }
}

So now the MainWindow constructor can look as follows.

public class MainWindow : Form {
    public MainWindow(CustomerManagement customerMgmt
        , SupplierManagementPresenterFactory supplierMgmt
        , InventoryManagementPresenterFactory inventoryMgmt
        , EmployeeManagementPresenterFactory employeeMgmt) {
        // Work your dependencies here...
    }
}

Then, depending on your business domain, the SupplierManagement could be intimately linked to your InventoryManagement, so that another aggregation could be done like so.

public class InventoryManagement {
    public InventoryManagement(InventoryManagementPresenterFactory inventoryMgmt
        , SupplierManagementPresenterFactory supplierMgmt) {
        // Work your dependencies here...
    }
}

So that you may further refactor to:

public class MainWindow : Form {
    public MainWindow(CustomerManagement customerMgmt
        , InventoryManagement inventoryMgmt
        , EmployeeManagementPresenterFactory employeeMgmt) {
        // Work your dependencies here...
    }
}

Now, as you can see, it is much simpler to understand what the MainWindow might do to serve its purpose. The idea behind is to group together what makes sense for your business domain. In another context, one might have prefered to group together the CustomerManagement, SupplierManagement and the EmployeeManagement as they have similar information to share as the Name, Address, Phone Number, Email, etc. This is primarily based on your needs. In the end, the role of the façade still holds same, to group together similar business features to add an abstraction layer and reduce complexity.

A very interesting article on the topic by Mark Seemann is Refactoring to Aggregate Services.

For more information on Design Patterns and Dependency Injection, I do recommend Mr. Seemann's book: Dependency Injection in .NET. Though the title states .NET, anyone wanting to learn about Dependency Injection and Design Patterns shall read it to grow one understanding on the topics and improve one skills. The example are easy to understand even if you're not from .NET.

Other interesting Q/A here on SO about the Façade Pattern

• What is Facade Design Pattern?
• Use of Façade Pattern

Disclaimer

I know your question is tagged Java and I posted C# code. This is meant for rapid answer off the top of my head. I think that though my samples are C#, you might easily understand the key point of the examples shown for the façade as they're simple, IMHO