Кроме тестирования, как Внедрение зависимости немного лучше, чем статические классы/методы?

Question

Кроме тестирования, как Внедрение зависимости немного лучше, чем статические классы/методы?

Python не вынуждает Вас в противный стиль one-class-per-file Java. На самом деле это даже не полагало, что хороший стиль помещает каждый класс в отдельный файл, если они не огромны. (Если они огромны, вероятно, необходимо сделать рефакторинг так или иначе.) Вместо этого необходимо сгруппировать подобные классы и функции в модулях. Например, если Вы пишете калькулятор GUI, Ваш макет раскладки мог бы быть похожим на это:

/amazingcalc
   /__init__.py # This makes it a Python package and importable.
   /evaluate.py # Contains the code to actually do calculations.
   /main.py # Starts the application
   /ui.py # Contains the code to make a pretty interface

5

c# architecture static dependency-injection

задан Beep beep 27 September 2009 в 04:50

4 ответа

Он позволяет вам заменять реализации без взлома кода. Например, в одном из моих приложений мы создали интерфейс под названием IDataService, который определял методы для запроса источника данных. Для первых нескольких производственных выпусков мы использовали реализацию Oracle с использованием nHibernate. Позже мы захотели перейти на объектную базу данных, поэтому мы написали и реализовали для db4o, добавили его сборку в каталог выполнения и изменили строку в файле конфигурации. Престо! Мы использовали db4o, не взламывая код.

1

ответ дан 14 December 2019 в 08:55

Это обсуждалось ровно 1002 раза. Вот одно такое обсуждение, которое я запомнил (читайте по порядку):

Что касается ваших конкретных проблем, похоже, что вы неправильно управляете образом жизни своих служб ... например, если одна из ваших служб отслеживает состояние (что должно быть довольно редко), она, вероятно, должна быть временной. Я рекомендую вам создать столько ТАК вопросов по этому поводу, сколько вам нужно, чтобы развеять все сомнения.

1

ответ дан 14 December 2019 в 08:55

Существует видео Guice , которое дает хороший пример использования DI. Если вы используете много сторонних сервисов, которые необходимо подключать к DI динамически. будет большим подспорьем.

0

ответ дан 14 December 2019 в 08:55

Другие вопросы по тегам:

c# architecture static dependency-injection

Похожие вопросы:

score 5 · Accepted Answer

The question for D.I. might be: is CreditEntityManager in fact the natural place to centralize knowledge about how to find a CreditEntity and where to go to CalculateScore?

I think the theory of D.I. is that a modular application involved in thing X doesn't necessarily know how to hook up with thing Y even though X needs Y.

In your example, you are showing the code flow after the service providers have been located and incorporated in data objects. At that point, sure, with and without D.I. it looks about the same, even potentially exactly the same depending on programming language, style, etc.

The key is how those different services are hooked up together. In D.I., potentially a third party object essentially does configuration management, but after that is done the code should be about the same. The point of D.I. isn't to improve later code but to try and match the modular nature of the problem with the modular nature of the program, in order to avoid having to edit modules and program logic that are logically correct, but are hooking up with the wrong service providers.