Запрос на дизайн / архитектуру программного обеспечения - PullRequest
0 голосов
/ 28 марта 2019

В книге «Шаблоны корпоративной архитектуры приложений» указано следующее:

Когда вы думаете о системе в терминах слоев, вы представляете основные подсистемы в программном обеспечении расположены в некоторой форме слоеный пирог, где каждый слой опирается на нижний слой. В этой схеме верхний уровень использует различные сервисы определяется нижним уровнем, но нижний уровень не знает о верхнем уровне.

С другой стороны, в книге «Гибкие принципы, модели и практики» говорится о принципе инверсии зависимости:

Модули высокого уровня не должны зависеть от модулей низкого уровня. Оба должны зависеть по абстракциям.

Это меня смущает. Я смешиваю две разные вещи здесь?

Ответы [ 2 ]

2 голосов
/ 28 марта 2019

Я полагаю, что это может говорить о некоторых одинаковых принципах, но на разных уровнях детализации. Однако я бы по-прежнему рассматривал инверсию зависимости как нечто само по себе.

В первом случае рассмотрим этот пример - в простой многоуровневой архитектуре у вас может быть уровень представления, встроенный в JavaScript, уровень бизнес-логики, встроенный в Java, и уровень данных в SQL Server. Эти слои могут быть разработаны различными группами людей. Уровень представления знает, как выполнять вызовы API на уровне бизнес-логики, но не наоборот. Уровень бизнес-логики знает, как читать / записывать на уровень базы данных и обратно, но не наоборот. Различие здесь происходит на высоком уровне - вы можете даже назвать это концептуальным.

Во втором случае вы хотите предотвратить сценарии, в которых предположительно универсальный код зависит от конкретных реализаций - и на этом этапе я рассматриваю его как относительно низкоуровневую проблему, которая попадает в область действия конкретного приложения (то есть в коде). не концептуально, как в предыдущем примере). Если у вас есть код, который пишет в базу данных, но вы хотите поддерживать различные реализации - например, MySQL и SQL Server, где каждый из них может иметь некоторые специфические сложности, не делают вызывающий код явно зависимым ни от одного из них - абстрагируют от сложности интерфейс. Это то, к чему обращается Принцип обращения зависимостей (см. Ниже).

    public class UserService {

        public UserRepository repository;

        public void setUserRepository(UserRepository repository) {
           this.repository = repository;  //Is this a MySqlRepository or a SqlServerRepository?  We don't care - the dependency is managed outside and we can change it without changing this class.
        }

        public void persistUser() {
            this.repository.persist(user);  //We just care about the abstraction - the interface.
        }
    }
0 голосов
/ 28 марта 2019

Здесь я смешиваю две разные вещи?

Да.

Первый случай касается зависимостей в время выполнения , в то время как второй случай касается зависимостей в время компиляции .

Например, во время выполнения бизнес-уровень может вызывать функции / методы, реализованные на уровне базы данных. Но во время компиляции код бизнес-уровня не упоминает никакого кода на уровне базы данных. Обычно это достигается с помощью полиморфизма.

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...