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

Читайте о фасаде, но не совсем разбираетесь в преимуществах использования, в первую очередь с помощью MVC. Может ли кто-нибудь помочь мне понять? Еще один практический пример? Извините за мое невежество!

Источник

3 ответа

Решение

Шаблон фасада - это совокупный сервис, который предоставляет несколько контекстных функций или сервисов.

Из Википедии

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

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

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

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

  • уменьшить зависимость внешнего кода от внутренней работы библиотеки, так как большая часть кода использует фасад, что обеспечивает большую гибкость при разработке системы; оберните плохо спроектированную коллекцию 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, не всегда черно-белые или такие очевидные.

Источник
Другие вопросы по тегам