В чем преимущество использования фасада вместе с MVC?

Facade Pattern – это совокупная служба, предоставляющая несколько контекстных функций или Сервисы.

Из Википедии

Шаблон фасада (или шаблон фасада) – это шаблон проектирования программного обеспечения, обычно используемый в объектно-ориентированном программировании. Название по аналогии с архитектурным фасадом.

Фасад – это объект, предоставляющий упрощенный интерфейс для большей части кода, например библиотеки классов. Фасад может:

• сделать программную библиотеку проще в использовании, понимании и тестировании, так как на фасаде есть удобные методы для общих задач;

• сделать библиотеку более читабельной по той же причине;

• уменьшить зависимость внешнего кода от внутренней работы библиотеки, поскольку большая часть кода использует внешний вид, что обеспечивает большую гибкость при разработке системы; оберните плохо спроектированный набор API-интерфейсов одним хорошо разработанным API-интерфейсом (в соответствии с потребностями задачи).

При этом, с моей точки зрения, у вас есть система учета, для которой основной формой является MDI, поэтому у вас есть несколько меню здесь и там, позволяющих пользователю получить доступ к этим функциям.

Чтобы избежать множественных зависимостей, вместо того, чтобы писать что-то вроде следующего:

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

когда вы ясно видите, что ваше MainWindow зависит от нескольких фабрик (или чего-то еще), пришло время рефакторинга. Один вопрос:

• Не слишком ли много зависимостей передано моему конструктору MainWindow?

Ответ ДА, у меня есть. Несмотря на это, моему MainWindow нужны все эти зависимости для выполнения его требований.

• Как выполнить рефакторинг, чтобы уменьшить количество зависимостей?

Можно сказать, что функции Past due invoices, Statement of accounts и Customer management должны быть объединены только в одну услугу. А вот и Фасад.

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

Итак, теперь конструктор MainWindow может выглядеть следующим образом.

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

Затем, в зависимости от вашего бизнес-домена, SupplierManagement может быть тесно связано с вашим InventoryManagement, чтобы можно было выполнить еще одну агрегацию.

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

Так что вы можете провести дальнейший рефакторинг:

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

Теперь, как видите, гораздо проще понять, что может делать MainWindow для выполнения своей задачи. Идея заключается в том, чтобы сгруппировать вместе то, что имеет смысл для вашего бизнеса. В другом контексте можно было бы предпочесть сгруппировать вместе CustomerManagement, SupplierManagement и EmployeeManagement, поскольку они имеют аналогичную информацию для совместного использования, как Name, Address, Phone Number, Email и т. д. Это в первую очередь зависит от ваших потребностей. В конце концов, роль фасада по-прежнему остается прежней: объединять схожие бизнес-функции, добавлять уровень абстракции и снижать сложность.

Очень интересная статья Mark Seemann на эту тему: Рефакторинг для объединения служб.

Для получения дополнительной информации о Design Patterns и Dependency Injection я рекомендую книгу г-на Симанна: Внедрение зависимостей в .NET . Хотя в заголовке указано .NET, любой, кто хочет узнать о Dependency Injection и Design Patterns, должен прочитать его, чтобы лучше понять темы и улучшить свои навыки. Пример легко понять, даже если вы не из .NET.

Другие интересные вопросы/ответы здесь, на SO, о шаблоне фасада

• Что такое шаблон проектирования фасада?
• Использование шаблона фасада

Отказ от ответственности

Я знаю, что ваш вопрос помечен Java, и я опубликовал код C#. Это предназначено для быстрого ответа с головы. Я думаю, что хотя мои примеры написаны на C#, вы можете легко понять ключевой момент примеров, показанных для фасада, поскольку они просты, ИМХО

Фасады предназначены для обертывания сложной функциональности, их основная цель — скрыть сложность базовой системы. Вы можете думать о Фасаде как о слое, обертывающем сложную функциональность и предоставляющем более простые методы для взаимодействия.

Он предоставляет интерфейс для клиента, с помощью которого клиент может получить доступ к системе. Этот тип шаблона проектирования относится к структурному шаблону, поскольку этот шаблон добавляет интерфейс к существующей системе, чтобы скрыть ее сложности.

MVC больше похож на общий способ мышления, когда речь идет о компьютерном дизайне. MVC можно было бы назвать в разговоре о веб-разработке или настольных приложениях, но с EJB или фасадами это действительно менее общее и более конкретное. «Раньше он обрабатывал все взаимодействия диспетчера транзакций и диспетчера постоянства». Вы будете использовать что-то подобное с JSF в качестве представления и JPA или Hibernate. Кроме того, использование EJB дает больше вариантов готового кода.

Иногда мне кажется, что различия между определенными предметами, такими как фасады и MVC, не всегда черно-белые или настолько очевидны.